Hi, The code I wrote implements the PubChem JSON format and the ChemDoodle JSON format:
https://github.com/mcs07/openbabel/blob/cjson/src/formats/chemdoodlejsonformat.cpp https://github.com/mcs07/openbabel/blob/cjson/src/formats/pubchemjsonformat.cpp It was just for me to learn how Open Babel works so I never got around to fully testing it and submitting a pull request, but I can do so if people are interested. Neither of these formats is really suitable as a proper standard Chemical JSON format, the PubChem one because it is ridiculously verbose and the ChemDoodle one because it's mainly designed just for depiction. Overall though, I personally I prefer a style closer to the ChemDoodle format, where the atoms and bonds are arrays of objects, as it matches up nicely with the internal data structure of most toolkits. Something like: { "atoms": [ { "element": 8, "x": 0, "y": 0}, { "element": 1, "x": 0, "y": 1}, { "element": 1, "x": 1, "y": 0} ], "bonds": [ { "begin": 0, "end": 1, "order": 1}, { "begin": 1, "end": 2, "order": 1} ], "charge": 0, "stereo": { ...? }, "properties" : { ...? } } This has the indices implicitly defined by the position in the array, but you could add an explicit "id" key to atoms and bonds if you wanted. One of the benefits of this style is that you can have optional keys on the atom objects (z coord, isotope, charge, radical etc.) and the bond objects (style:wedge, aromatic:true, etc.). I also wonder whether JSON-LD (http://json-ld.org) could possibly be used to make the format extensible, so people could define their own custom keys on the atom and bond objects (or in a separate properties object) and have some way of making it understandable to other toolkits. Matt On 6 Jun 2013, at 22:23, Dimitri Maziuk <dmaz...@bmrb.wisc.edu> wrote: > On 06/06/2013 04:11 PM, Patrick Fuller wrote: >> Tim, >> >> I think Dimitri's point is that all the references are implicitly defined >> by list indices, rather than explicit keys. > > ... > >> While i somewhat agree with Dimitri's point about the stability associated >> with lost bits (explicit keys will hold up better to a lost comma byte than >> list indices), I also think that it's up to the socket infrastructure to >> validate transmitted data. > > You can't validate bugs in someone else's code. Especially if they're > "features". If there are 3 numbers missing, you can't tell if it's a > missing atom (perhaps a side-chain proton they expect you to add?) or 3 > different atoms missing one coordinate each. > > As far as compact representations go, '{ "CID" : "6324" }' is both more > compact and contains more information: I can urlopen the sdf into OBMol > and get all sorts of data out. Except for the name -- the only way I can > get to the word "ethane" is by generating and inchi string and querying > our own ligand database... but only if the molecule is a PDB ligand. > > -- > Dimitri Maziuk > Programmer/sysadmin > BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j_______________________________________________ > OpenBabel-discuss mailing list > OpenBabel-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openbabel-discuss ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ OpenBabel-discuss mailing list OpenBabel-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-discuss
