W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > May 2009

Re: Question about standardization

From: Oliver Ruebenacker <curoli@gmail.com>
Date: Wed, 13 May 2009 11:29:26 -0400
Message-ID: <5639badd0905130829m494c8ca1t705c3c1d307b8453@mail.gmail.com>
To: Bijan Parsia <bparsia@cs.man.ac.uk>
Cc: public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>, Michael Hucka <mhucka@caltech.edu>
     Hello Bijan, All,

  The sympathy might not come across as intended if you throw such
weighty issues as rechartering at newcomers.

  The rhetorical question was not intended as a blow, but to elicit
some more information on what makes a thing substantially worthy of
standardization. I was hoping to get something more enlightening than
an all too obvious example.

  My impression is that the SBML community is more than capable of
providing an engineer day per week. I am wondering, are we talking
here about developing or recognizing a standard, or is there any such
distinction at all at W3C? I can imagine that developing a standard is
costly, but I would guess recognition to be way less costly. (For
grouchy people: Forgive my know-nothing arrogance. This is neither
intended as a rhetorical question nor a dialectical blow)

     Take care

On Wed, May 13, 2009 at 6:21 AM, Bijan Parsia <bparsia@cs.man.ac.uk> wrote:
> On 13 May 2009, at 10:48, Oliver Ruebenacker wrote:
>>     Hello Bijan, Michael, All,
>>  The group does not deliver standards, but can submit something for
>> consideration to W3C.
> Hence my care in distinguishing what the group can and cannot do.
>>  I remember this being discussed indetail in one
>> of the phone conferences.
> Well, if you would read a little more carefully, you wouldn't have to
> remember.
>>  If SBML is not deserving of being a standard, the what is?
>> Something
>> no one uses?
> Ah yes, non sequiturial rhetorical questions that were obviously intended as
> a crushing dialectical blow, and succeed at being such --- just not in the
> intended direction.
> There are a host of reasons to undertake standardization in a formal
> standards body and a host of reasons not to. The best one, in my opinion, is
> ensuring interoperability of existing systems (i.e., to reduce competition
> at one level to enable better competition at another level). In my opinion,
> standardization shouldn't be regarded as something akin to publishing a
> journal article (i.e., a sanctioned archival representation of a body of
> significant work). (BTW, this is just to give an example of what I would
> consider a bad reason, not to remotely suggest that this is "the reason" for
> pursuing SBML standardization. I don't *know* what the reasons are for
> pursuing SBML standardization, hence my asking for, you know, a reasonable
> discussion of the rationale. That discussion has to happen as there lots of
> people you have to convince aside from me.)
> Standardization has costs that can harm efforts. It drains time, energy,
> money, control. For example, the standard expected commitment of an
> organization to a W3C WG is on engineer day a week (more, if you're an
> editor). A WG is a committee that you do not control the membership of.
> Indeed, that is the W3C...you have to convince a lot of people who *properly
> do not care about SBML* (or OWL, or...) that it's worth diverting the
> *extremely limited* resources the W3C has to SBML.
> There's a lot of politics since there are limited resources. Your sort of
> know-nothing arrogance will, I suspect, play rather poorly. It is so playing
> with me and I started this conversation fairly sympathetic to SBML.
> I've been involved in lots of W3C WGs both inside and outside the semantic
> web area and am trying to offer considered, reasoned, helpful advice based
> on my experience and understanding of the process. If you don't want that
> input, then yay. I'll stop now.
> Cheers,
> Bijan.

Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
Received on Wednesday, 13 May 2009 15:30:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:40 UTC