<div dir="ltr"><div>Hi Saulius,</div><div><br></div><div>thanks a lot for your answer!</div><div>The COD conversion runs nearly 100% now - for the water (oxygen) molecules addresses by us. There are many more problematic atom_names, as shown in your lists. <br></div><div><br></div><div>Our heuristics is slightly different from yours and does interpret many of the problematic names too, but if this interpretation is right or wrong nobody knows. Next to your lists provided in the email we also experience many atom_names like ?, n or simply a dot or an empty space, which are not interpreted at all by us.<br></div><div><br></div><div>I fully agree with your plans a) and b)! In the end no heuristics is error proof. It will be a big step forwards and a great improvement on the COD quality, when as many CIF's as possible carry atom_symbols next to the atom_names.</div><div><br></div><div>We will fix the "OWat(n)" atom_name and hope to have our conversion ready by the beginning of next week.  <br></div><div><br></div><div>best regards,</div><div>Thomas Dortmann<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 13, 2020 at 8:21 PM Saulius Gražulis <<a href="mailto:grazulis@ibt.lt">grazulis@ibt.lt</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Thomas,<br>
<br>
On 2020-01-13 12:43, Thomas Dortmann wrote:<br>
> a) concerning atom-labels:<br>
> <br>
> we fixed the "Wat" atom-label in our conversion and now the number of pattern containing the (wrong!) element Astatine is down from 1180 to  8!<br>
> These eight remaining patterns are all minerals, where water is coded as "OWat(n)" instead of "Wat";<br>
> these are the corresponding CIF's:<br>
> 9006364 - 9006368<br>
> 9014246<br>
> 9014312<br>
> 9016377<br>
<br>
This is good news. I'm very happy that your conversion software runs<br>
nearly 100%!<br>
<br>
On my side, I went through the "uncanonical" atom names in the COD<br>
(<a href="http://saulius-grazulis.lt/~saulius/.d981490889b10e82e8f6943bbfd569aaebf1c8c3/" rel="noreferrer" target="_blank">http://saulius-grazulis.lt/~saulius/.d981490889b10e82e8f6943bbfd569aaebf1c8c3/</a>).<br>
In the file "estimated-atom-types.lst", the first column is the<br>
estimated atom type, the second is the atom name in the corresponding<br>
CIF, and the third is the number of occurrences of this atom name.<br>
<br>
The "DOUBLE_CHECK.lst" contains a manually compiled list of atom types<br>
that are most probably wrong after automatic detection and will need to<br>
be inspected by a human.<br>
<br>
The policy I would adopt is the following:<br>
<br>
a/ If a CIF already contains _atom_site_type_symbol, we do nothing.<br>
<br>
Reason: the _atom_site_type_symbol is either added manually by COD<br>
curators (in this case we do not want to undo our manual work), or it is<br>
provided by CIF authors. Among the atom type symbols, most common<br>
irregularity is the symbols in all lowercase, or the symbols in all<br>
uppercase. These can be dealt by regularising case an looking up in a<br>
table; e.g. we do:<br>
<br>
ucfirst(lc($atom_type_symbol)),<br>
<br>
where lc($string) returns all-lowercase version of the argument string,<br>
and ucfirst($string) returns the string with the first letter<br>
uppercases, yielding "Ca" from both "ca" and "CA", which is mostly<br>
correct. From 14742 atoms in the COD that have _atom_site_type_symbol<br>
values, only 28 could not be interpreted in this way – a negligible<br>
amount, and non-correctable even manually.<br>
<br>
Since, as I understand, you software already incorporates this<br>
heuristics, atoms with _atom_site_type_symbol will not be a problem,<br>
will it?<br>
<br>
b/ If the atom does *not* have the _atom_site_type_symbol, we will guess<br>
its type from the atom label. If the leading non-digit characters of the<br>
atom label yield a valid periodic system element name, we do nothing.<br>
<br>
If the leading non-digit characters of the atom site label do *not*<br>
yield a recognisable atom name, we apply heuristics as noted in the<br>
estimated-atom-types.lst.log in the Web page cited above; in Perl:<br>
<br>
$n1 = ucfirst(substr($atom_site_label,0,1));<br>
$n2 = ucfirst(lc(substr($atom_site_label,0,2)));<br>
<br>
if( $atom_site_label =~ /^Wat[A-Za-z0-9\(\)]*$/ ) {<br>
    $atom_site_type_symbol = "O"<br>
} elsif( exists $COD::AtomProperties::atoms{$n2} ) {<br>
    $atom_site_type_symbol = $n2<br>
} elsif( exists $COD::AtomProperties::atoms{$n1} ) {<br>
    $atom_site_type_symbol = $n1<br>
} else {<br>
    $atom_site_type_symbol = "?";<br>
    print STDERR "$0: WARNING, atom type for atom \"$F[1]\" is not<br>
recognised\n"<br>
}<br>
<br>
We then compute the summary formula with the new atom types, and compare<br>
it with the formula provided by the authors. If the summary formulae<br>
match, we add the _atom_site_type_symbol to the CIF. If not, we report<br>
an error.<br>
<br>
After this, we double-check the atom types mentioned in DOUBLE_CHECK.lst.<br>
<br>
The new modified CIFs will have recognisable (standard) element names in<br>
_atom_site_type_symbol, and will have correct chemical formula<br>
computable from atom records (correct means the same as provided by the<br>
author). The results will be like to those in estimated-atom-types.lst.<br>
<br>
The new CIFs may only break the heuristics in you program if:<br>
<br>
1/ we guess the atom types wrongly,<br>
2/ the authors provided an incorrect summary chemical formula<br>
3/ the two incorrect formulas match by pure accident,<br>
4/ your heuristics gets atoms types correctly.<br>
<br>
or<br>
<br>
1'/ we make two mistakes that compensate each other exactly (e.g. Ca->C<br>
on one site, and C->Ca on another site) and still get the correct<br>
formula with incorrect atom site assignments.<br>
<br>
I regard coincidence of these events highly unlikely. Also, when<br>
detected, the _atom_site_type_symbol values can be curated manually and<br>
will *not* be overridden again by automatic software.<br>
<br>
If you find such COD curation policy acceptable, we proceed with its<br>
implementation at some time in the future, and add it to our automatic<br>
pipelines (but without the manual check stage for every incoming file...).<br>
<br>
I CC this e-ail to the COD AB for discussion and eventual policy approval.<br>
<br>
Regards,<br>
Saulius<br>
<br>
-- <br>
Dr. Saulius Gražulis<br>
Vilnius University Institute of Biotechnology, Saulėtekio al. 7<br>
LT-10257 Vilnius, Lietuva (Lithuania)<br>
fax: (+370-5)-2234367 / phone (office): (+370-5)-2234353<br>
mobile: (+370-684)-49802, (+370-614)-36366<br>
</blockquote></div>
<br />-- 
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.