On Fri, Feb 19, 2010 at 3:06 PM, Peter Murray-Rust <[email protected]> wrote: > This does not mean that there is a universal absolute right to absolute > modification, but that the process of modification should be formalized. > Within that some things will be permitted or encourgaed and others will be > forbidden or discouraged.
I believe modification through a formalized process creates routes to intellectual monopoly. <snip> >> I am not worried about fragmentation. Human habits is not to favor >> small project and small forks; instead, the best 'fork' wins. > > I take a completely different view here. There were several early > implementations of CML done without my knowledge or the simple courtesy of > contacting me/Henry. There are programs supplied by commercial companies > which "save as CML" and the CML is not conformant. One company simply > wrapped a load of completely random XML in <cml>... </cml> wrappers. Then > people try to read this and it fails and they blame CML. So right to modify > a spec without consultation and in any way I believe is harmful. CML has various means of validation, one particular part I very much like about CML. I am surprised to hear and find it hard to believe that people blame the standard instead of the tool that actually created the file. Should the definition of an Open Specification/Standard be affected by people being so lazy to actually understand what is going on? Should the OS freedoms be determined by documents which are not conform that specification? Wrapping something in <cml>... </cml> does not make that document CML. I am not convinced about that argument. >> This is how it works for Open Source too, and soon Open Data likely >> too. I see no reason why allowing 'modification' would immediately >> cause heavy fragmentation, and loss of momentum; I do not understand >> the source of this fear... did I miss an important example where >> allowing this caused the specification project to die? > > CML was developed specifically for the process of creating a > machine-readable specification that could enforce validation (as far as I am > aware it's the only one in chemistry). There are several variations in CML > allowing controlled flexibility. They include CMLSpect, CMLComp and CMLLite > to be released at ACS. The former two were developed by consultation between > several groups. They are not a dicatorial imposition. However they do > provide conformance processes. A typical example was JSpecview where RobertL > wished to restrict the type of CML data that the program could accept and > reject. He made the decision, not me. IMO that's a good example of community > process. So what defines a Open Specification/Standard community process? As discussed, various closed-considered formats did work in a community process. Why are they closed, and the CML community open? > "Community process" does not mean an anarchic free-for-all where anyone can > do anything. It means a process where interested members of the community > can have their voice heard and their contributions accepted if appropriate. > It does not necessarily rely on a majority voting system. It certainly > involves work on governance which is hard and time-consuming. It cannot be > controlled by specifying the process in a licence. With the community process Andrew describes for SMILES, I do not see why it would not qualify as Open. > It's worth thinking about Openness in MDL-molfile has evolved. It certainly > was not even public let alon Open when it was first deployed (I ran a > meeting in 1983 where this was a significant issue). How so? What requirements did it not meet at that stage? > It's gradually evolved > to a stage where it is widely distributed and widely used - and there are > validators - we wrote one for CML with MDL's psonsorship. In that sense > it's a community process. However as far as I know there are no Open methods > for it to evolve. It's copyright Symyx (and probably trademarked) and The term Linux is also trademarked. CML is also copyrighted. > Symyx have the legal right to forbid any mofication of the spec. Which is fine according to the discussion! People keep repeating that modification is not a requirement... > As far as I know > neither MDL or Symyx has made any offical statement about the public > modification of MDL-mol. Would you qualify that as requirement for an Open Standard? > AFAIK they are disinteredly benevolent but it's still their spec, not ours. The CML specification is yours, not mine. I might have very small patches in there, but I would not consider CML 'mine' or 'ours'. > So I regard MDL as de facto openly accessible and implementable but not > modifiable. Thus Open? Egon -- Post-doc @ Uppsala University Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Blueobelisk-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
