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.
-----
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.
The phrases should probably be something like:
- openly shared and distributed
- open to multiple implementations
- open to improvement
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. Calling it "freely
modifiable" seems like the wrong tone.
---
I like this because it emphasizes community norms instead of formal
licences. [I'd suggest the last reads "open to improvement through community
processes."] 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]
The nearly-2-years discussion has emphasized the inappropriateness of
licences for data. 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.
Here are parts of the Panton principles to show the language - they do NOT,
of course, translate to Open Specs but they emphasize the problems with
licences
1. *When publishing data make an explicit and robust statement of your
wishes.
2.*Many widely recognized licenses are not intended for, and are not
appropriate for, data or collections of data. *Use a recognized waiver or
license that is appropriate for data
3.**If you want your data to be effectively used and added to by others it
should be open as defined by the Open Knowledge/Data
Definition<http://opendefinition.org/>– in particular non-commercial
and other restrictive clauses should not be
used.
4. **Explicit dedication of data underlying published science into the
public domain via PDDL or CCZero is strongly recommended and ensures
compliance with both the Science Commons Protocol for Implementing Open
Access
Data<http://sciencecommons.org/projects/publishing/open-access-data-protocol/>and
the Open
Knowledge/Data Definition <http://opendefinition.org/>.*
--
Peter Murray-Rust
Reader in Molecular Informatics
Unilever Centre, Dep. Of Chemistry
University of Cambridge
CB2 1EW, UK
+44-1223-763069
------------------------------------------------------------------------------
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
