Subject: Re: CCL:Chemical MIME types

From: [email-masked] (David J. States)
Date: Thu, 30 Jun 1994 09:45:37 +0600

There is a real need for a chemical MIME type.  Molecules are a very
basic elements of reality, and chemists have developed an extensive
formalism to describe them.  Being able to exchange basic chemical
information between applicatons would be extremely useful.  The chemical
community also needs better agreement on standards.  You can download a
.gif file and expect to view it.  Transfering a coordinate set from one
application to another is much a more speculative proposition.

FASTA format macromolecular sequence data should be a secondary MIME
type.  Even though it is ambiguous (you can only statistically guess
whether the data is a nucleic acid (4 letter alphabet) or a protein (20
letters)), FASTA is the most widely supported sequence format in use.

There should also be an additional protein sequence secondary type,
either SwissProt or PIR (or both).  The GCG format is proprietary and
not supported by all packages, and the NSBI/ASN format is very complex
and also not widely supported outside of NCBI software.  How much of
the NCBI/ASN.1 definitions are you proposing to include?  The chemical
definitions are embedded in a much broader definition set encompassing
everything from bibliographic citations to the syntax for defining a
gene.  Because the definitions are highly cross-referenced, teasing out
just chemistry would be difficult.

Should a CAS registry number be a MIME type?  I guess I raise it to
oppose it.  They really do not communicate the data, only a pointer to
it, and the registry numbers have been closely protected by CAS.  For
example, I don't think CAS would allow a general RN <-> SMILES string
table to be distributed freely.  If they did, I would reconsider.

Do I hear anyone volunteering to maintain a general secondary MIME type
coercion filter so that users need only have a limited number of
viewers on their system and programmers could limit their target?

David States
Institute for Biomedical Computing / Washington University in St. Louis