On 17 May 2009, at 20:07, Michael Hucka wrote:
[snip]
OK, I understand now. I'm happy to start here, then.
mhucka> Indeed. Standardization of SBML has been discussed
mhucka> over many years in the SBML community,
bparsia>
bparsia> Pointers?
Probably the earliest mention with a record online is a
presentation I did in at an SBML workshop in 2003, titled
"Organizing the SBML Standardization Process" [1]. After
that, it was generally discussed verbally at subsequent
workshops. I can't immediately find a specific presentation
about it after the one in 2003. Around 2005 +/- a year, it
was decided (again during verbal discussions at an SBML
Forum meeting) that it wasn't a pressing issue and that
resources were better put to other things, so the matter was
put on the back burner.
So there's a change now? Seems so from what you write below.
[snip]
* I was recently contacted by a software group at a large
international company, asking about licensing terms for
using SBML. Currently, there are no explicit terms; SBML
is open, and the SBML editors and contributors always
considered no one to be the owner of SBML. This turned
out to be problematic for the company: no terms of use, no
copyright, no patent terms, etc., meant they didn't know
what was permitted and what wasn't, and they pointed out
that if no one owns SBML, then no one can grant rights to
using SBML either.
This is a standard and excellent reason to go the standardization
route at an organization (like the W3C or, I believe, OASIS or OMG)
that has an IP policy.
Although in the end the company's
lawyers went ahead and green-lighted the project, it
brought to light the weakness of SBML's current scheme
(and it made me wonder how many other commercial
developers might have turned away without asking). Now,
an obvious approach would be to add copyrights and license
terms ourselves to the current specifications.
You should do that anyway (and need to in order to proceed with e.g.,
a member submission), but patent concerns are hard to handle without
an org like the W3C.
The SBML
Editors actually started trying to do that a couple of
weeks ago, and we quickly ran into the question of who
would hold the rights. SBML has involved many people over
the years; attempting to establish copyrights among
ourselves seems to lead to either every institution having
to be listed, or someone taking it alone. The former
seems impossible; the latter seems unfair.
You need to clear copyright on the text. A reasonable story is that
only the people who contributed physical text are copyright owners
(you can liberalize that a little). The key is to get all of them to
ceded copyright to *someone*.
My sense is
that trying to have a neutral standards organization
(e.g., W3C) do it, would be acceptable to individuals and
institutions.
A good way to do this, short term, is via a member submission which
requires a license to the W3C, e.g.,
http://www.w3.org/Submission/2008/04/
That doesn't address development or patent issues, of course. But it's
a good first step and a good first step toward standardization.
[snip]
This is an excellent reason, in my book.
* SBML has so far been endorsed by a very large user base,
in terms of actual, functioning software that uses SBML,
and published models expressed in SBML, and people who
recognize and use SBML in their work. Nevertheless,
several other languages have been proposed over the years,
and new ones continue to appear. To people working in
this field, I think there is no question of what is the
closest to being a "standard". However, to people who are
coming at it from the outside (for example, trying to
figure out what they should use in their own modeling, or
what to implement in their software, or what to encourage
in journal publication guidelines), there is apparently
not the same level of clarity.
[snip]
Competing, near-equivalent proposals muddying the waters...another
excellent reason.
However, recognize that people who have been developing these other
proposals have an interest in either *their* language being
standardized, or, at least, some say at the table. This means a
"lightweight" standardization process is less likely. This is a reason
to do it at someplace like the W3C, but it might be a good idea to
start thinking less about standardizing SBML per se and more about
standardizing a "Biological Modeling Language" to which SBML is one
(but a major! input).
Of course, if all the rivals are fine with it, then no problem :)
I believe this confusion is increasingly hurting the
biological modeling field -- it doesn't help
interoperability and it doesn't help commercial developers
sell products, which are two important things that we need
in order for the field to grow and mature. For the past
several years, I personally didn't worry much about
getting standards-body approval because I thought if we
pressed ahead with SBML and made it work for as many
people as we could, eventually the rest would sort itself
out. I now think this was naive, and that SBML needs more
than that. Getting the imprimatur of a well-respected
body such as the W3C would settle the issue, and let
competition move on to new topics, further helping the
field to mature and move forward. Otherwise, I think
we'll continue to be in this situation where everyone
claims theirs is a standard.
Pitch a wide tent, if you can. If you can unify proposals *before*
standardization, do so. The more buy in from the more disparate
parties, the better.
One way to do this other than HCLS (at the W3C) is to start an
Incubator Group:
http://www.w3.org/2005/Incubator/
An XG is like a very lightweight WG which, again, cannot produce
recommendations, but it can produce a report that sometimes is fast
tracked toward standardization. The clearest example of this is the
POWDER wg which came out of the Web Content Label XG:
http://www.w3.org/2007/02/powder_charter
I would *personally* say that an XG is a better idea than trying for a
task force within HCLS. In some sense, it's all W3C so who cares. But
an XG is focused and is in a better position to pull in people who
really only care about working on the biological modeling language and
might feel overwhelmed by everything that HCLS is doing. (That's not
to say that HCLS wouldn't have a role.)
XGs are pretty easy to get going. You just need 3 w3c members to
request to start one.
* There are indeed varying degrees of conformance among the
software packages currently supporting SBML. Developing a
"stronger", more precise technical specification would, I
think, help improve that. Hopefully, having a "true"
standard to work towards would also serve as an incentive
for commercial efforts to produce fully conformant
implementations. Again, this would help interoperability
and the field in general.
So, it sounds like to me that there are technical issues as well as
the afore mentioned social/political issues. This really suggests to
me an XG.
* The SBML process is home-grown and still relatively
informal. It has served well enough so far, for mostly
academic open-source developers and researchers, and a few
commercial closed-source developers. But it only works as
long as there are not too many people involved, and the
people play nicely. The latter hasn't always happened,
but we've been lucky so far in that the most disruptive
people have tended either to lose interest or leave.
Looking ahead a few years, when (hopefully) SBML will
involve a lot more people, I'm concerned that this process
will not be sufficient. I don't feel we are capable by
ourselves of developing a process that's sufficient to the
task, and besides, it doesn't seem to make sense to try,
when other groups have already gone through the pain and
achieved hard-won, working solutions. The W3C's process
appears stronger and better suited to larger undertakings
by parties that may have a lot of different agendas. This
seems better, for the sake of SBML in the future. (The
process is also a lot heavier, as you pointed out. This
is an important consideration. The pros and cons still
need to be debated.) In summary, I think it would benefit
the SBML community to partner with HCLSIG/W3C to work
toward a more scalable process.
Sounds reasonable.
(In another message:)
bparsia> HCLSIG cannot, itself, standardize SBML under the
bparsia> current charter. HCLSIG can, of course, do a lot
bparsia> of things that make standardization of SBML more
bparsia> likely. One thing it to publicize it, evangelize
bparsia> it, and gather evidence of consensus behind
bparsia> it. Not only can it do these things for various
bparsia> technologies, it's arguably part of its purpose.
Yes, it seems to me HCLSIG is a good starting point for this
effort. At the very least, it should help clarify what will
be needed in the long run, and whether it's worth it.
Yeah, but I'd also consider an XG if you're serious about moving
forward.
An XG is also a good way to "test out" the process and the group.
Cheers,
Bijan.
