Subject: CML resources

From: Peter Murray-Rust <[email-masked]> (by way of Rzepa, Henry)
Date: Wed, 19 May 1999 08:21:00 +0100

Greetings
	
	I am delighted to see the interest in markup languages on this list
and to offer CML as a way forward for molecular information components. As
Henry Rzepa has announced, we have recently submitted a paper on CML and the
latest DTD has been posted on http://www.xml-cml.org

	CML/CML is ideal for the management of input and output to chemistry
codes. A feature of many of these is that the output has an overall structure
which includes well described components (e.g. coordinates, energies,
frequencies, wavefunctions), but that the order and quantities of
occurrence may depend on the control input and the actual course of the
calculation (e.g. when convergence was reached). XML is ideal for holding
this information as it is essentially a tree structure and can be built
with minimal effort. The exciting thing about XML is that all the tools to
manage this structure are now freely available (search, filter, diff/merge,
etc.) It means that postprocessors for these codes are easy to write and
the resulting XML is extremely rich.

I have written a considerable number of such postprocessors (in Java) which
extend the JUMBO browser. This means that a single tool (JUMBO) can browse
the output of all the standard codes. [Some of the postprocessors were
written for JUMBO1, now obsolete, but can be easily modified if required. I
would be delighted to advise.] All these postprocessors will be mounted
(with OpenSource) on xml-cml.org and you are very welcome to browse them.

A number of examples of the use and power of XML are available in the
tutorial and other material at http://www.xml-cml.org. It includes, for
example, a postprocessor for the VAMP code.

Of course the ideal place for creating CML is inside the chemistry codes
themselves. This should be almost trivial, and again I'd be happy to
advise. Note that the latest version of the CML DTD (the specification) has
been thoroughly tested and is likely to remain stable for an appropriate
time. 

CML is designed to be extended in a number of directions. If atoms (or
bonds) have a large number of "columns" it is trivial to add these. For
example if you wish to create an atom property for the calculated 13C shift
the output could resemble:
<atom>
  <float dictname="13C" convention="MY_THEO_PROG" units="ppm">111.1</float>
...
</atom>
The implication here is that there would be a publicly available ontology
(dictionary) for MY_THEO_PROG explaining what "13C" meant. In this way all
the scalar quantities output from a code could be described and captured
precisely.

Matrix properties can also be captured in CML (there is a <matrix>
XMLelement) and this can be contained in any CML element. Thus atoms can
have matrices attached to them in irregular fashion. For example a few
atoms in a list might have quadrupoles, while others might have dipoles,
etc. XML an manage this irregularity very easily. It is straightforward to
use *standard* XML tools to search for (say) all atoms with 3*3 matrices.
using XQL this looks like:
	//atom/matrix[rows='3' $and% columns='3']
This comes free-out-of-the box!

CML is a truly component-based approach to information. Thus CML does not
define mathematics (it uses MathML), nor bibliography (uses DOCBOOK), not
graphics (uses SVG). In this way a complex piece of information (e.g. a
theoretical publication) can be built up from its components.  This is
complete synthesis of documents and data and heralds the way for
"interactive publications" - including theses - that can be re-input into
programs and can be read in a completely interactive manner.

I have looked at a considerable number of theochem outputs and am
reasonably confident that the CML tools (which include scalar and matrix
primitives) can cope with everything in the common programs. The key thing
is for authors to produce their dictionaries/manuals/ontologies in XML and
then finally we shall have a complete markup of all the components.

At Nottingham we have a project (BioDOM) to support XML in bioinformatics
(essentially macro- and small molecules). Adam Moore has written converters
for Swissprot and PDB and also posted a number of XML resources on the site.

CML is deliberately intended to be a community approach. We are starting to
get a number of organisations who are serious about building public and
private systems with CML components. Moving CML i/o into the widely used
codes would be a tremendous boos to the community and - we believe - to the
use of codes and the re-use of the data they produce.

	P.

-------------------------------------------------------------------------