 |  |
 |  | |  | |  | |  | |  | |  | |
|
The SketchEl molecule format is described. This format is used by all MMI products, as it preserves all molecular diagram properties with no loss of data. |
Overview
The SketchEl molecule format was developed for the SketchEl open source project, which is hosted on SourceForge. It is used by all MMI software for storing 2D molecular structures. Products such as MMDS represent molecules using an internal datastructure which can be mapped directly to the SketchEl molecule format, which can be interconverted with no information loss.
The format is largely equivalent to the basic properties of an MDL MOL file. A large proportion of ordinary molecules can be converted between SketchEl and MDL MOL formats without information loss, but it should be noted that there are some differences which are crucial for certain types of molecules. In particular, the SketchEl molecule format provides additional information for describing implicit hydrogens and has more available bond orders, which are vital for describing molecular structures that do not follow the Lewis octet rule. The MDL MOL format has a very long list of properties which are not usually used for describing individual small molecules, e.g. query features, stereochemical mixtures, polymer units, etc., none of which are explicitly supported by the SketchEl format.
The only features included in the SketchEl format are those which have cheminformatic meaning. The SketchEl format is not intended to be used to describe a drawing, but rather it describes a molecular species with enough detail to ascertain its chemical composition and enough information to produce a drawing from it. This distinction is important, because it means that the format has no properties for encoding drawing style (e.g. font size, line width, colour, double bond positioning, etc.), and it has no fields for additional decorations (e.g. text labels, reaction arrows, molecular orbital lobes). All of these additional properties and decorations can be accomplished in other ways, but they are not a part of the core molecule format.
Because the format is minimalistic, and all of the features have a well defined meaning, it is straightforward to interpret a SketchEl molecule in its raw form. Additional properties about the molecular structure need to be calculated after the fact (e.g. aromaticity, stereochemical parity), or stored in an ancilliary field within a datasheet, or they can be encoded as arbitrary data within the atom or bond extension fields, and interpreted as and when necessary.
Specification
- The preferred file extension is .el, and the MIME type is chemical/x-sketchel.
- The format is strictly 7-bit ASCII.
- UNIX-style line separation should be used by default, i.e. "\n", but MSDOS-style ("\r\n") should always be accepted when encountered.
- Whitespace padding should never be used.
-
With the exception of separators, all characters which are not pure ASCII, or are control codes (in the range 0 .. 31), or
are one of the following forbidden characters: space (
- The escape code syntax is: \hhhh, where the four digits following the backslash are hexadecimal encoding for a 2-byte unicode character. Thus, some of the otherwise unavailable characters are encoded as:
- Integers are encoded in plain denary, while floating point numbers are encoded using English-style decimal, using the period separator for the fractional part. Scientific notation is not used.
- There is no limit to line length. Readers should not use a fixed line size.
-
The first 9 bytes of the format must correspond to the ASCII "SketchEl!" (hex:
53 6b 65 74 63 68 45 6c 21 ), which is the recognition string.
\0020 space \005C \ \002C , \003B ; \000A newline |
Outline
A SketchEl character stream is described by the following pattern:
SketchEl!({#atoms},{#bonds})
{element}={x},{y};{charge},{unpaired}[,i{implicit}][,e{explicit}][,n{mapnum}][,...]
...
{from}-{to}={order},{type}[,...]
...
!End
|
- On the first line, {#atoms} and {#bonds} are given. The total number of lines between the SketchEl! and !End tags must be equal to the sum of these values.
- The {element} field is used to provide a symbol for each atom. It may correspond to an atom in the periodic table, or it may contain any alternate text, as long as forbidden characters are properly escaped out. There is no mandated maximum length. For purposes of interpretation, if the element is not a part of the periodic table, it should be treated as a placeholder, with a molecular weight of 0.
- The coordinates for the atom are given first, then the remaining properties follow, separated by a semicolon. Note that the boundary between coordinates and other properties uses a different separator, in order to reserve the right to supplement the {x} and {y} coordinates with {z}, at a later date. Readers of the format should not refuse to read the input if a third coordinate is included, though they are not at this point required to carry the value along with the datastructure.
- Following the coordinates, the {charge} and {unpaired} fields are mandatory. Both are integers, and are most commonly zero.
- {charge} is the whole ionic charge associated with the atom. Partial charges are not allowed.
- {unpaired} - the number of unpaired electrons - is usually used to denote radicals. For first row organic atoms, a value of 1 means that the atom is a radical, and has one less implicit hydrogen than might otherwise be expected, e.g. methyl radical with three singly bonded substituents. Beyond monoradical organic elements, this field should be used as a somewhat subjective hint regarding spin state.
-
Any number of data entries can follow on an atom line, but each of them must begin with a single character prefix, which
describes what type of data follows, i.e. the whole field is appended to the line as: ,{id}{content}. If the content
contains forbidden characters, they must be escaped out. Values of {id} are all reserved for official fields to be added at
a later date. The currently available values are:
- i: the calculated implicit hydrogen count. When encountered, it means that the implicit hydrogen count is unconstrained, and that the number of implicit hydrogen atoms should be recalculated every time its state changes. For example, a methyl substituent has 3 implicit hydrogens, but if it is singly bonded to another carbon, the sketcher application should decrement this number, for convenience. The normal field value for methyl would be i3, which shows the most recently calculated number of implicit hydrogens. The number is included, so that reader applications are not forced to derive their own implicit hydrogen counting algorithm, and can merely read out the correct value.
- e: the explicit hydrogen count, which supercedes the implicit count. The presence of this field means that the user has specified the exact number of additional hydrogens which reside on the atom, and that this number is not open for interpretation, even if the environment of the atom changes.
- n: the mapping index number, which is an arbitrary integer, which has an implied value of 0 if absent. Referring selected atoms to some alternate numbering scheme, for external purposes, is commonly useful.
- m: the isotope mass, which is an integer that should correspond to the integer mass of the singular nucleus type, e.g. 2 for deuterium, 13 for carbon-13, etc. The default value, 0, means that the atoms are statistically distributed according to natural abundance.
- x: invariant expansion field. The value of the content should be ignored, unless the application recognises header codes that it understands. There is no specific convention for embedding atom-specific data, but it is prudent to include the name of the application responsible for the extra field, e.g. x$SOMEPROGRAM$SUBSTITUENT#1234. An application which reads a SketchEl file should retain all of these expansion fields, associated with the original atoms, unless the atom is actually deleted. This expansion field is used for data which is not dependent on the entire molecule.
- y: dependent expansion field. As for x, except that the properties of this field are tied to the whole molecule. If the reader program does not recognise the expansion field, and the data is modified, then this property must be invalidated. For example, storing calculated partial charge might be done with y$TOPOLOGICAL$PARTIAL_CHARGE=0.3327. If the structure is modified, then the field is no longer valid, and so it must be deleted.
- All other single-character field prefixes are reserved for future use. Unrecognised expansion fields should be treated in the same way as x, i.e. the value should be preserved, unless the atom is deleted.
- It is valid to use these fields more than once in order to encode multiple properties, e.g. xTHING1,xTHING2. In cases where a field value is understood to have a meaning that overrides a previous field, the latest value should be used.
- Bonds are described by four integer values, in edge-list format, followed by an arbitrary number of expansion fields. Bonds must not be redundant, i.e. no two bonds may have the same connection points.
- Bond {from} and {to} must have values which are between 1 and the number of atoms.
- Bond {order} is an integer between 0 and 4.
- Bond {type} is a number, for which values between 0 and 3 are currently defined. Unrecognised bond types may be retained or converted to 0, at the discretion of the application. 0 encodes a "normal" bond, with no special properties. 1 encodes "inclined" (or "up-wedge"), where the destination atom is considered to be higher than the source atom relative to the plane of the page (or "Z-axis"), while 2 encodes "declined" (or "down-wedge"), where the destination atom is lower than the source atom. A value of 3 is the unknown stereochemistry type, drawn as a "squiggly" line, which implies that the atoms on either end have undefined stereochemistry, which may encode for a mixture, or undefined.
- Normal bond types are directionless, so [from,to] is the same as [to,from]. Inclined or declined bonds, however, must be ordered such that the first atom is the source, which is usually rendered as the thin end of the "wedge". The direction of the wedge has important implications for encoding of stereochemistry.
- Custom data entries for bonds have the same form as for atoms: ,{id}{content}, where {id} should be x for invariant fields, and y for those which should be removed whenever the molecule is modified.
A very simple example - ethanol with implicit hydrogens - is as follows:
|
 |
A second example, based on the same heavy-atom ethanol structure, is an example of how to not to make a cheminformatically meaningful structure, but nonetheless demonstrates some features of the format:
|
 |
All 3 atoms, and both bonds, have an invariant expansion string, and a dependent expansion string. The latter will all be removed if the slightest modification is made to the structure. The third atom, oxygen, is represented by an escape code (hex 4f), which is valid even when the raw character is allowed. The first atom is assigned a charge of +1, and its hydrogen count is assigned automatically, and was calculated to be 2. The second atom is assigned a number of hydrogen atoms to be fixed at 2, which coincidently happens to be the same number as would be automatically calculated for a methylene. The third atom is a radical oxygen, with 1 unpaired electron, and an automatic hydrogen count which happens to be 0.
Both of the bonds are ordered so that atom 2 is the source point, and the bond types are inclined and declined, respectively, which has no stereochemical meaning since the central carbon atom has symmetry.
Abbreviations
Inline atom abbreviations are an extension to the core format, which allow atoms to be labelled with abbreviation codes, e.g. Et, tBu, Ph, etc., and retain embedded versions of the abbreviated structure fragment. Because each abbreviation retains its structural content within the description of the molecule, it is still possible to derive the molecular formula correctly without having to resort to an external lookup table. Also, abbreviations can be defined for custom purposes and do not need to be standardised. It is straightforward to expand out abbreviations to obtain a fully atom-specified structure. The structures of inline abbreviations may contain their own inline abbreviations, which are encoded recursively.
Software that is capable of reading and writing the core SketchEl format will gracefully ignore abbreviations: the abbreviation labels will be displayed, but their meaning will be unknown. Modifying atoms that do not contain abbreviations is defined to be safe through multiple read/write cycles, which provides a measure of forward compatibility.
Consider the following example of butylbenzene:
Structure (a) shows the all heavy atom structure, while structure (b) shows the representation which uses Bu to represent the butyl substituent, and (c) shows the definition of the abbreviation.
The SketchEl format representation of (b) is encoded as follows:
SketchEl!(7,7)
C=6.1000,0.2500;0,0,i0
C=4.8010,-0.5000;0,0,i1
C=7.3990,-0.5000;0,0,i1
C=4.8010,-2.0000;0,0,i1
C=6.1000,-2.7500;0,0,i1
C=7.3990,-2.0000;0,0,i1
Bu=6.1000,1.7500;0,0,i0,aSketchEl!(5\002C4)\000A*\003D6.1000\002C0.2500\003B0\002C0\002Ci0\000AC\003D6.1000\002C1.7500
\003B0\002C0\002Ci2\000AC\003D7.3990\002C2.4999\003B0\002C0\002Ci2\000AC\003D7.3990\002C4.0000
\003B0\002C0\002Ci2\000AC\003D8.6981\002C4.7500\003B0\002C0\002Ci3\000A2-3\003D1\002C0\000A3-4
\003D1\002C0\000A4-5\003D1\002C0\000A2-1\003D1\002C0\000A!End\000A
1-2=1,0
1-3=2,0
2-4=2,0
4-5=1,0
5-6=2,0
6-3=1,0
1-7=1,0
!End
(NOTE: extra newlines added for clarity)
|
Atom 7 has the element label Bu. It is an otherwise unremarkable atom placeholder, except for the extension field: aSketchEl!(5\002C4)\000A*.... The prefix a is not defined in the core format, so it is treated as an invariant expansion field. The content following the letter a is processed using the escape codes, such is why the long string shown above contains so many backslashes.
The definition for the Bu "atom" contains the full structure (c) in the diagram above. This abbreviation definition contains 5 atoms. The first atom has the label "*", and the remaining 4 atoms are carbons. The first atom must be defined with an asterisk as the element type. It is a special placeholder atom.
When the primary structure and the inline abbreviation are considered together, they are defined as the union of the two structures, where the primary placeholder atom (in this case Bu) and the abbreviation placeholder atom (always the first atom, and with the label *) are deleted. The bond to the abbreviation in the primary structure (i.e. the connection between the phenyl ring and Bu) is deleted, and the bond (or bonds) from the inline abbreviation are used to create them:
As a general rule, the inline abbreviations should contain quality structure coordinates, which means that an alignment of the analogous placeholder atoms by rotation and translation, as suggested in the diagram above, should produce a reasonably readable structure depiction, at least without taking into account congestion.
Abbreviations are defined to be strictly terminal, i.e. the atoms of the inline group may be connected to only one of the atoms in the main structure. However, the attachment point may be connected by multiple bonds to atoms within the abbreviation itself. Consider a metal centre bonded to an acetylacetonato ligand:
This coordination geometry can be expressed in terms of an abbreviation (acac), and its definition:
Note that the inline abbreviation has one placeholder atom, *, which is bonded to both of the oxygen atoms of the ligand. In the primary structure representation, the acac abbreviation is connected to the copper atom by one connection point. The fully expanded structure is fully equivalent to the abbreviated version, because when the abbreviation is expanded, the Cu-acac bond is deleted, and the two bonds from the inline abbreviation (one single, one zero-order) are used to replace it. In this way molecular formula, hydrogen atom calculations and valence counting are all preserved.
Comments
Some notes on the nuances of the SketchEl molecule format are described below.
Bond orders
Nonzero bond orders are considered to carry significant meaning, and provide a fairly strong hint as to the pi localisation of electrons within the molecular structure, and resonance patterns thereof. Most organic species can be represented by using bond orders 1 through 3. In the vastness of chemistry, however, most possible structures have some number of bonds for which this assignment is misleading, and so a bond order of 0 should be used to denote a bonding interaction of indeterminate degree. Dative bonds, strong hydrogen bonds and multicentre bonds all qualify. This is a particularly useful interpretation hint for metal-organic structures, where part of the molecule has conventional bonding patterns (usually the organic part), while the interface (typically to the metal) would invalidate normal valence rules.
 |
Consider the fictional platinum complex above. If all of the connections were represented using double or single bonds, an interpretation of the bonding patterns would have to conclude that not all of the atoms are valid Lewis structures, and none of the bond orders have useful meaning. With selected use of zero-order (dotted) bonds, however, considerable information about the structure falls into shape quite easily.
The dimethylamine ligand has a coordination bond to the platinum metal, which means that it is reasonable to guess that the number of hydrogen atoms on the nitrogen atom is 1, which is correct. If the coordination bond were drawn as a single line, the ligand would be considered to be an anionic ligand, with no hydrogen atom. On the other side, the pyridine-platinum connection is also described as a zero order bond, which preserves the valence of the aromatic system. The pyridine ring can readily be interpreted as a relatively normal 6-ring aromatic system, rather than a hypervalent non-octet species. The platinum centre has four ligands, two of which are zero order, and two of which are single bonds. Combined with no overall charge, this suggests that the oxidation state is that of Pt(II), which is the commonly accepted designation. On the other side of the pyridine substituent, a hydroxy substituent is shown in a chelated H-bond arrangement with the adjacent ketone. Use of a zero-order bond allows this to be expressed, without drawing a divalent hydrogen atom, and thereby upsetting the otherwise neat and tidy valences.
Stereochemistry
All stereochemical features are represented by the atom position and bond style. There are no additional fields for chirality. Parity-style assignments, such as the CIP R/S or E/Z systems, must be calculated as needed. Part of the reason for this is that all sketches are considered to be potentially a work-in-progress. Assigning a definitive parity to an atom or bond loses meaning as the molecule is modified, permuted, rotated etc. For sketching purposes, it is far more practical to recalculate these properties from the sketch, and never encode them as fixed values.
For stereochemistry which is unknown, or mixed, the unknown bond type can be used. For chiral centres, the mere absence of inclined or declined "wedge bonds" is sufficient. The format draws no distinction between unresolved stereochemistry and mixtures. There is no inherent capability for describing multiple species within a single structure, whether it be stereochemistry, tautomers, isomers, or any other kind of 'mer. This is a deliberate design decision. Systems which try to encode a large amount of chemistry within a single sketch are inevitably either too complex, or too limiting. Mixtures of distinctly different molecular species should be drawn as individual sketches, which has the benefit of being specific, simple and foolproof, at the expense of convenience.
Implicit hydrogen atoms
One of the most problematic side effects of the most popular molecular sketch formats is the inability to reliably reconcile the drawing with the corresponding molecular formula, due to over-reliance on automatic calculation of the number of implicit hydrogens attached to the heavy atoms which are explicitly drawn as part of the sketch.
For most organic compounds, the number of implied hydrogens is quite simple to calculate, since most of the constituents are first row p-block atoms, and the valences are mostly Lewis-octet based, and it is usually obvious when this is not the case. However, in the absence of a way to mark an atom as not being eligible for automatic implicit hydrogens, problem cases quickly rack up when leaving this comfort zone.
For a good illustration, consider the following two sketches:
 |
Both of these compounds show a tin atom connected by single bonds to two substituents. The dimethyl tin compound on the left could be dimethyl tin(II), or it could be dimethyl tin(IV) dihydride. Since the former is an extremely reactive intermediate, and the latter is commercially available, it would be quite reasonable to guess than two implicit hydrogen atoms should be added to top up the valence to make a tin(IV) compound. The dichloro tin compound on the right, however, is more likely to be tin(II) chloride, i.e. adding two implicit hydrogens would most likely be a mistake. However, no matter how good the algorithm is for picking the most likely state, whether to add or not to add is still just a guess, and the author of the sketch could may intended to represent the other possibility.
This is clearly unacceptable, since authors of sketches generally know how many hydrogens they want on each of their atoms. Being unable to correctly recalculate the molecular formula of the input structure is a case of unnecessary information loss.
The SketchEl molecule format does not prescribe a method for calculating implicit hydrogens, although the formula that it uses internally is conservative. Rather, it has two states:
- Automatic (default). The number of implicit hydrogens is recalculated whenever the atom environment changes, e.g. the atom element or charge is changed, or its bonding environment is altered.
- Specific. The user has indicated exactly how many hydrogens are attached to the atom, and this will not be modified.
The actual hydrogen-count formulae used by MMDS (and SketchEl) are:
| Element | Formula |
|---|---|
| C | 4 - |charge| - unpaired - Σ bondorder |
| N, P | 3 + charge - unpaired - Σ bondorder |
| O, S | 2 + charge - unpaired - Σ bondorder |
Any element not in the list has an automatic implicit hydrogen count of zero. Calculated values of less than zero are set to zero. Note that carbon atoms use the absolute value of the atom charge. The bond order sum is the total bond order of all connected neighbours, and is used literally, i.e. a bond order of 0 has no impact on the hydrogen counting.
Only five elements are eligible for receiving automatic hydrogen atoms. The remainder of the periodic table consists mainly of atoms to which an attached hydrogen atom is a notable feature. A neutral terminal carbon atom with 3 hydrogens (methyl) is very uninteresting, and sketches are more legible if they are not shown, and more likely to be correct if the user is not required to provide this information. A tin(IV) centre with two methyl groups and two hydridic hydrogen substituents should display its metal-hydrogen substituents proudly, and requires additional specification to confirm that they are intentional.
In practice, automatic hydrogen calculation is very useful when sketching molecules, since most atoms are either part of a Lewis-compliant fragment, or are atoms for which implicit hydrogens are never automatically added. The explicit hydrogen field can either be used by setting to 0 and drawing hydrogens as actual atoms, or it can be used to force a certain number to be associated with the atom, and drawn as part of the label when displayed.
One of the functional requirements of the format is that the list of atoms plus the number of implicit hydrogens recorded in the atom blocks of the format must make up the entire molecular formula. Some or all of the hydrogen atom counts will usually be calculated automatically, but it is the author's task to ensure that this is overridden manually whenever this would have led to the wrong answer.
See Also
  |
| © 2010-2011 Molecular Materials Informatics Inc. All rights reserved. Last modified 31-Aug-2011 |
||||||||||||
