Re: Question about standardization

Hi Mike,
It's good to hear from you.

Would you be interested in having a call to discuss the various options?

Cheers,

Susie


On Sun, May 17, 2009 at 4:56 PM, Bijan Parsia
<bparsia@cs.manchester.ac.uk>wrote:

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