On Fri, Feb 19, 2010 at 2:08 PM, Peter Murray-Rust <pm...@cam.ac.uk> wrote: > GeoffH has made a useful suggestion (on the BO Stack Overflow, > http://blueobelisk.stackexchange.com/questions/231/what-formats-fall-into-open-specification) > which I'd be happy to take as a starting point.
Likewise... > ----- > If [a spec/standard] is freely modifiable, then it's likely to fragment. > Look at HTML for an example. > > OpenSMILES is, perhaps, an interesting example, since there's an open group > working on the specification. But the same is true of HTML. Interestingly... you could argue that OpenSMILES is a fork of SMILES. That is, SMILES is sufficiently open to even allow OpenSMILES. > The phrases should probably be something like: > > openly shared and distributed > open to multiple implementations > open to improvement The latter is to me a rather important part: allowing modification. We formalize this by means of licenses in Open Source, and by means of waivers and licenses in Open Data. *But* for both we reached the consensus that the right for modification should be formalized. > In short, there's a mechanism to clarify implementation details (and/or a > set of validation tests), and some sort of community process. > > I'm still not sure if you can avoid HTML (or PDB or SDF) fragmentation. But > I think that's in line with what you're suggesting. I am not worried about fragmentation. Human habits is not to favor small project and small forks; instead, the best 'fork' wins. > Calling it "freely modifiable" seems like the wrong tone. > --- How so? > I like this because it emphasizes community norms instead of formal > licences. [I'd suggest the last reads "open to improvement through community > processes."] The Panton principles promote formality in Open Data. Please explain. > We've been going through this process for Open Data and are > launching the "Panton Principles" today - http://pantonprinciples.org/. [I > hope the BO feels they are useful for its OpenData] Everyone can endorse the PPs via the above linked website. > The nearly-2-years discussion has emphasized the inappropriateness of > licences for data. Yet the PP suggest to use a recognized license (or waiver). Please explain. > Instead it is more useful to the authors and the > community to express what they feel is important and to iterate toward a > rough consensus. In my own case of CML I completely sign up to all Geoff's > suggestions. CML is sharable and distributable, there are several > coordinated multiple implementations and there is a community process (open > mailing list, contributors from outside the authorship). The balance between > fragmentation and innovation is a difficult one and can be best be managed > through open discussion and creation of software artifacts. 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? Peter, it's been too long since I visited your group, and the last time I only chance to talk to Nico... I'm a bit lost in following your argumentation, and see several inconsistencies, resulting from not being able to follow your thinking... and, I'm eager to get things clear, because I am pretty sure we are still on the same line... Grtz, 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 Blueobelisk-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
