Smiles to molfile

Call Vendor A API to convert smiles to molfile catch(VendorAException ex) ... 

Consider the extended SQL functions smiles to molfile and molfile to smiles. Having these functions available as SQL extensions allows one to export a molfile from a table containing SMILES. For example ... 

Select smiles, smiles to molfile(smiles) from atable ... 

The CHORD6 chemical cartridge is a commercial product from gNova, Inc. It is written using C functions and the OEChem toolkit from OpenEye. It provides the core functions discussed in this book, such as cansmiles, matches, count matches, list matches, smiles to molfile, molfile to smiles, and xform. CHORD makes it possible to efficiently process RDBMS tables containing many millions of chemical structures. 

Create Or Replace Function smiles to molfile(text) Returns Text As EOPERL ... 

Create Or Replace Function frowns.smiles to molfile(smi Text, name Text, coords Numeric ] [] ) Returns Text As EOPY from frowns import Smiles... 

Select frowns.smiles to molfile( 1, null, null) ... 

The recommendation here is to use SMILES to store molecular structure itself. If other features of the molecule or atoms need to be stored, other data types and columns can be added to the row describing the molecule. It is the "SQL way" to not encode a lot of information into one data type. When using a molfile as the structural data type, too much data is encoded in a single data type. The individual data items must be parsed and validated. Errors creep into the data, due to missing, extra, or invalid portions of the molfile. Ways of storing atomic coordinates, atom types, and molecular properties are discussed Chapter 11. 

The external representation of molecular structure is a less rigorous definition. For example, there are many programs available that can convert to and from SMILES and molfiles. These can be used when a molfile (the external representation) needs to be imported as a SMILES (the internal representation) into the database. Similarly, a SMILES can be easily exported as a SMILES or converted to a molfile or other file format. It is useful to have these conversion functions as SQL extensions. 

The basic idea of specifying the priority of the atoms around a stereocenter in order to obtain a stereodescriptor is also incorporated into the most widespread structure representations, the Molfile and SMILES (see Sections 2.3.3, and 2.4.6). 

A SMILES code [22], MDL Molfile [50], or JME s own compact format (one-line representation of a molecule or reaction including the 2D coordinates) of created molecules may be generated. The created SMILES is independent of the way the molecule was drawn (unique SMILES see Section 2.3.3). Extensions to JME developed in cooperation with H. Rzepa and P. Murray-Rust also allow output of molecules in the CML format [60]. 

Chemical representation can be rule-based or descriptive. Here we will give a short description of two popular file formats for molecular structures, MOLfiles (9) and SMILES (10-13), to illustrate how molecules are represented in computer. SMILES is a rule-based format while MOLfile is a more descriptive one. 

SMILES strings are very concise and hence are suitable for storing and transporting a large number of molecular structures, while MOLfiles and its extension SDFiles have the option to store more complicated molecular data such as 3D molecular conformational information and biological data associated with the molecules. There are many other file formats not discussed here. Interested readers can find a list of file types at the following web site http //www.ch.ic.ac.uk/chemime/. 

Here is a real-world example for illustrative purposes. Suppose you have a chemical information system that has to support both Molfile and Smiles structures and a business method in a business object has to get the mol-weight and molformula from the Molstructure objects to fulfill its responsibilities. A naive design is to have two versions of the business method one takes a Molfile structure object as input and another takes a Smiles structure as input (Figure 2.4). 

Suppose we want to develop a module that represents the chemical structure of compounds. A structure is the signature of a compound that, in most cases, uniquely defines all chemical properties of the compound such as mol-weight, molformula, stereo chemistry, pKa, and logP. Suppose a structure can be represented in many different formats—Molfile, Chime, Smiles. The algorithms of calculating the chemical properties are different depending on the structure format, and our application has to support all of them. A naive solution is to develop a class for each structure format and repeat every common attribute and method in all of them. 

It defines two simple methods. The molfileToSmiles() method converts a Molfile string to a Smiles string. The smilesToMolfile() method does the opposite—converting a Smiles string to a Molfile string. They both throw MolstructureConversionException to flag conversion failures. The failure can be caused by exceptions from the vendor implementation or from the CRS code. 

The vendor tools that you end up using may have completely different APIs. But you should not care when you design the interfaces of your system. Remember, the vendor API may not be the best design, or at least it may not be ideal for your system. All you need to care about is what makes the most sense to the clients that use the structure conversion API in your system. To do the conversion between Molfile and Smiles, the above API is the simplest. 

Call Vendor B API to convert molfile to smiles catch(VendorBException ex) ... 

The same approach can be used for property calculations, because you may have multiple choices and each one has different APIs. It is possible that today you choose one vendor solution to do the work. Some time in the future you may switch to a different vendor for the purpose of cost savings, better algorithm, performance, or reliability. Or you may face a harder choice—the vendor you chose in the past is going out of business. The solution we described above for Molfile-Smiles conversion keeps your system closed for... 

For users who prefer to draw in new structures, the later versions of Chem Draw will deliver a SMILES notation which can be used via cut and paste commands, and ISIS Draw delivers a MOLfile which can be automatically converted to a SMILES file. ACD / LogP uses a proprietary drawing program, MolDraw, which is easy to learn and use. Entry by name in ACD is accomplished via a Dictionary with about 48,000 entries. Drawn structures can be saved to a file, but in version beta 0.9 of ACD/LogP there is no method of batch entry from either SMILES files or MDL MOLfiles. 

The most commonly used identifiers today include line notation identifiers (e.g., Simplified Molecular Input Line Entry System [SMILES] and International Chemical Identifier [InChls]), tabular identifiers (e.g., Molfile and Structure Definition [SD] file types), and portable mark-up language identifiers (e.g., Chemical Markup Language [CML] and FlexMol). Each identifier has its strengths and weaknesses as detailed in Chapter 5. Chapters 5 and 6 provide enough information to guide researchers in choosing the most appropriate formats for their individual use. 

Another choice for the internal representation of molecular structure is a molfile. It would be possible to construct SQL functions like those described in this chapter that would operate on this type of data. One disadvantage of molfiles is their greater size compared with SMILES. One advantage is that it is possible to store atomic coordinates, which is not possible with SMILES. There are other molecular file formats, but these are substantially the same as a molfile, except perhaps for specific atom types that may be of use in some database applications. 

---