SketchEl: Molecule Format

SketchEl preferentially uses its own data format to describe molecular sketches. The native format is structured plain ASCII text, consisting of some number of atoms and bonds. The format is minimalistic, rigid, and slightly extensible.

The SketchEl molecule format is also used natively by the Mobile Molecular DataSheet for BlackBerry smartphones.

The philosophy underlying the SketchEl molecule format can be summarised as: the fewest possible primitives needed to capture a molecule drawing, or drawing in progress, with only features which have cheminformatic semantics, preferably orthogonal. When it comes down to it, there are very few data features which fit into these criteria. Molecular diagrams are frequently adorned with additional labels which are not directly connected to the molecular formula of the molecular species being described, e.g. registration codes, enantiopurity, reaction stoichiometry, molecular orbital lobes, etc. Many formats have fields for information which, in principle, is derivable from more basic properties of the sketch, e.g. aromaticity, partial bond order, chiral parity, etc. Furthermore, many formats have a variety of fields which are specific to particular types of chemistry or downstream purposes, e.g. reactivity, query features, mixture data, etc.

The SketchEl native format has no place for all of this fancy additional markup. What it does have is everything that is needed to perform a basic interpretation of the cheminformatic properties of the molecular species being described. Anything that cannot be expressed with the available primitives must be provided as data which is supplementary to the molecular sketch - which is not as onerous as it sounds.

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 ( ), backslash (\), comma (,) semicolon (;) or equals (=), must be replaced with an "escape code".

• 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:

          \0020  space
          \005C  \
          \002C  ,
          \003B  ;
          \000A  newline
  

• 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.

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, unless there is a preestablished contract between the provider and consumer of the chemical data.

• 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 atom 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.

• 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:

SketchEl!(3,2) C=-6.9500,6.5500;0,0,i3 C=-5.6510,7.3000;0,0,i2 O=-4.3519,6.5500;0,0,i1 1-2=1,0 2-3=1,0 !End

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:

SketchEl!(3,2) C=-6.4000,2.3500;1,0,i2,xPERM1,yTEMP1 C=-5.1010,3.1000;0,0,e2,xPERM2,yTEMP2 \004F=-3.8019,2.3500;0,1,i0,xPERM3,yTEMP3 2-1=1,1,xPERM12,yTEMP12 2-3=1,2,xPERM23,yTEMP23 !End

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.

Comments

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 have 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:

1. 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.

2. Specific. The user has indicated exactly how many hydrogens are attached to the atom, and this will not be modified.

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. Explicit hydrogen atom specification is most often useful for specifying that a particular atom will always have 0 implicit hydrogens. If there are any hydrogens to be attached, they will be drawn in as actual atoms.

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.

Back to SketchEl main page