On Thu, Jun 6, 2013 at 2:11 PM, Patrick Fuller <patrickful...@gmail.com>wrote:
> Tim,
>
> I think Dimitri's point is that all the references are implicitly defined
> by list indices, rather than explicit keys. For example, something like
>
> {
> "atoms": {
> "C1": { "element": "C", "location": [ 0.230811, 0.380820, -0.610968 ]
> },
> "C2": { "element": "C", "location": [ -0.230811, -0.380820, 0.610968
> ] }
> },
> "bonds": [
> { "atoms": [ "C1", "C2" ], "order": 1 }
> ]}
>
> will result in generally cleaner code. That is,
> molecule["atoms"]["C1"]["location"] is easier to understand than
> molecule["elements"]["coords"]["3d"][0]. In that regard, I completely
> agree with him.
>
If you're going to rely on positions within arrays, why not just do it the
simple way?
{ "smiles": ["CCO"],
"2D": [1,1,2,2,3,3],
"3D": [1,1,1,2,2,2,3,3,3]
}
The atoms are indexed left-to-right in the SMILES. That's it. Everything
else keys to that.
A SMILES contains exactly the same information as the atom/bond lists in a
much more compact form. If you want to avoid the aromaticity problem, just
use Kekule form, which makes it virtually identical to any other connection
table format, but in about 10x to 20x fewer bytes. SMILES are very easy to
parse, and there are dozens of parsers around.
If we're going to invent yet-another-file-format, can't we at least move
past 1970s atom/bond table technology?
Craig
------------------------------------------------------------------------------
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
