-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday 04 June 2004 15:20, Bob Hanson wrote: > I can see this CIF thing really isn't a standard. Bummer. But this > source is an important one, as it is the main crystallographic database > for the entire small-molecule world.
It *is* a standard... but there it allows for more than one dictionary... each
dictionary is well described. There are as many possible ways as there are
dictionaries...
I haven't seen the file and don't know what documentation there is for it, so I'm guessing. [If *part* of it were posted here I could make a better comment.] My guess is:
- it is well-formed CIF - i.e. does not throw syntactic errors
- it contains dictionary items that are not in the IUCr core cif dictionary
- it may contain values which are ontologically at variance with that dictionary.
- it *might* contain MIF items
There is a superset of CIF, called STAR which has roughly equivalent power to XML. There is a format MIF for holding chemical information which is not widely used but can, I think, occur in CIF files from CCDC. MIF is conformant to STAR, but whether it uses any
non-CIF constructs in this instance I don't know.
Assuming all of this the problem is isomorphic to (say) a CML file, perhaps with embedded SVG. The whole file conforms to the syntax, but the interpretation of some of the components is difficult or impossible. For example if the MIF or non-CORE CCDC dictionaries are absent you can only guess at the ontology. The question is whether you cause serious problems by omitting the bits you can't understand. At the moment I am not clear why the file can't be read. The most likely problem would be that Jmol required a particular piece of information and that was missing, or present in a different semantics.
Some examples from CML:
<atom> <atomParity atomRefs4="a1 a2 a3 a4"/> </atom>
This is well-formed but invalid CML. Atom must have an id attribute. Assume: <atom id="a4"> <atomParity atomRefs4="a1 a2 a3 a4"/> </atom>
This is arguably valid but semantically broken - atomParity must have a value denoting the chirality:
<atom id="a4">
<atomParity atomRefs4="a1 a2 a3 a4">1</atom>
</atom>
Now atomParity is probably meaningless to Jmol (it describes the chirality of the atom but Jmol does not currently do anything with it - and it is difficult to see how it could. CDK and JCP are different). It can ignore it with no ill-effect.
So for extensible formats such as CIF and CML programs like Jmol should be tolerant of missing information and of information they cannot interpret - not regard these as broken.
P.
Peter Murray-Rust Unilever Centre for Molecular Informatics Chemistry Department, Cambridge University Lensfield Road, CAMBRIDGE, CB2 1EW, UK Tel: +44-1223-763069
------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
