Connection table formats

Almost all chemical information systems work with tlicir own special type of connection table. They often use various formats distinguishing between internal and external connection tables. In most cases, the internal connection tables arc redundant, thus allowing maximum flexibility and increasing the speed of data processing. The external connection tables are usually non-redundant in order to save disk space. Although a connection table can be cprcsented in many different ways, the core remains the same the list of atoms and the list of bonds. Thus, the conversion of one connection table format into another is usually a fairly straightforward task. 

MDL Molfile. mol Molfile the most widely used connection table format ummmdli.com 50... 

Our present reaction rule database is made up of approximately one hundred rules adapted from a microfiche generously sent to us by Gelernter (4). For a given reaction, a rule specifies the reactants (subgoal) and the product(s) (goal), in connection table format and any constraints on their composition (Figure 2a). The rules are identified by chapter and schema numbers. The connection tables are organized as follows ... 

There have been numerous attempts to develop standard connection table formats for data exchange, almost all of which have sunk rapidly and without trace. An XML-based connection table format, Chemical Markup Language (CML) was proposed in the late 1990s and has now reached version 2.4 which incorporates a number of extensions for representation of features such as spectra, reactions and polymers. Though there is now an extensive CML literature, its adoption by commercial software vendors has thus far been very limited. Greater penetration has been achieved by the lUPAC Chemical Identifier, which is essentially a highly-compacted connection table, discussed in the next section. 

Most computer systems have their own connection table formats for disk storage, and such connection tables can only be written or read by one particular system. Some manufacturers who produce a range of programs for handling chemical structures use a single connection table format which can be written or read by all programs in their range. Such formats do, however, remain proprietary products of individual companies, and their exact descriptions are not always pubUcly available. 

Several proposals have been made for standard connection table formats in recent years. These have generally been put forward by particular user communities, and are geared to the requirements of that user community. 

There are only three fundamental ways in which connection table formats differ what information is stored, how that information is represented, and how those representations are encoded. GEMINI achieves a high degree of generality by dividing its task into these three parts. 

A string-processing language is used to specify a connection table format. This language allows succinct specification of both the content and encoding of most external formats that we have encountered, but is currently Umited to character-oriented files. 

Chemicals are usually stored in computer-readable format as data which represent a valence structure. For historical reasons, the external format for such data is commonly referred to as a connection table. A majority of connection table formats are simply formatted versions of an internal data structure written out in tabular format. However, a significant number of non-tabular formats are used for external computer representation of chemicals. 

There is a large number of different connection table formats in active use today (probably in excess of 100). Several factors contribute to the proliferation of different formats for the same fundamental purpose. The most important of these are ... 

Connection table formats are often invented to serve a specific application. Different apphcations require storage of different kinds of information. 

There is no standard connection table format that has been uniformly accepted by the chemical information community. 

A connection table format can be considered a special-purpose external database format which is used to store a limited amount of chemical information. Our goal is to produce a method which allows accurate description and interpretation of connection tables in the general case. 

Not all connection table formats contain all these t5rpes of information. Formats can therefore be information deficient with respect to one another. 

Each connection table format specifies one or more representations for each kind of information that it can contain. A representation is a rigorous system for characterising a particular kind of information. An adequate representation must not be information-deficient with respect to the information that it represents. For example, internal co-ordinates, local chirality, R/S, and bond parity are four different adequate representations of absolute chirality information. Adequate representations can be converted between each other algorithmically. Fortunately,... 

Connection table formats specify an encoding for each kind of informational representation which can be used. An encoding is a convention used to indicate the possible values that representations can take. The number of possible encodings for any given representation is very high. For example, the R/S representation of absolute chirality can be encoded as the characters R and S , the digits 1 and 2 , or many others. 

A complete encoding convention for a connection table format also specifies how the representational encodings are organised (e.g., in a file or character stream). 

The approach used here for connection table interpretation assumes that there are limited numbers of kinds of information which exist in the desired formats, and that it is known how to convert the information from each of these to a suitable internal form. The interpretation of any instance of a connection table can then be divided into two completely independent parts extracting the information from the table and converting it to internal form. This allows automated interpretation, given the meaning (representation and encoding) of each field of a connection table format. 

Estabhsh a set of information types which is adequate to describe the information contained in the desired connection table formats. Select a single data representation and encoding for each type of information this will become GEMINI S internal encoding. 

Collect the set of data representations used in the desired connection table formats, and select a single encoding convention for each one. This will be known as the set of transfer variables. 

The choice of the set of variables used internally to represent transfer information is not critical as long as it accurately describes all information to be derived from the desired connection table format. A slight benefit is associated with choosing a set of variables which store information independently. Any encoding convention may be used which is adequate to specify all desired values (including missing, as appropriate). 

Note that the set of transfer variables is redundant with respect to the variables used in the internal encoding (i.e., an internal variable can be specified by more than one transfer variable). This is a natural consequence of the multiplicity of representations available for connection table information. Furthermore, a connection table format may be inherently redundant (i.e., the same information may be specified more than once, or in more than one way). Therefore, another algorithm is needed to specify the order that conversion algorithms are applied to the transfer variables to produce an internal encoding. This algorithm is listed in Table 2. 

A CONNECTION TABLE FORMAT (CTF) DESCRIPTION LANGUAGE General... 

DESCRIPTION "TriPos MOL-1 connection table format (used by SYBYL)" FILETYPES .SYB. MOL. MOLl"... 

The CTF description language appears to be flexible enough to describe the vast majority of connection table formats in use today, and extensible enough to be adapted to those likely to arise in the future. A practical limitation of the language as described here is the inability to handle binary data conveniently. If interpretation of binary connection table formats becomes important, binary-oriented translation operators could be added to the language. 

An intriguing possibility is creating a language to describe the converse operation, i.e., one which describes how to write a connection table, rather than read it. This would, in principle, allow any connection table format describable in the language to be converted to any other. 

Support software must be developed in each of these areas and integrated into the DBMS for every new abstract data t3q>e. For example, to create a chemical structure ADT, a storage format, such as a connection table format, must first be defined. Then operators for full structure, substructure, and other types ol structure searches must be defined. Access methods need to be implemented to provide fast structure searches and finally, the characteristics of the various structure searches must be made known to the query optimiser to allow efficient overall query execution. 

The first step in the creation of a new data type is the definition of the data structure for the type. In Cousin, structures are stored in a typical connection table format with atom and bond counts, and fists of atom and bond attributes. Atom attributes include atom type, co-ordinates, charge, isotope, and attached hydrogen count. Bond attributes are bond type and connecting atom numbers. 

---