Tony Williams ('Chemspiderman') posted an interesting article on his weblog at http://www.chemspider.com/blog/we-need-an-inchikey-resolver-and-we-need-it-now.html
dealing with the 'translation' of an InChIKey back to a structural diagram via a 'lookup-service'.
I like Tony's idea of an Inchikey-resolver and I would like to support it. The only questions/remarks I have, deals with the efficiency of such a process in our world of 'parallel systems'.
A few facts first:
At the moment approx. 33 millions of organics are known. Chemspider holds approx. 21M, PUBCHEM-Compounds approx. 18M structures, which represents 2/3 of known chemistry. I know that within CHEMSPIDER structure correction is an ongoing process as it is e.g. within my own CSEARCH-project. NMRshiftdb has been severly improved over the last months, etc.
Now all these systems exchange structures ..... 'A' gets 10,000 structures from 'B', 'A' does some corrections and gives its structures to 'C'. 'B' doesnt know A's corrections and gives also its structures to 'C'. Now 'C' has 2 "versions" of the same structure - in principle you can ignore that for an Inchikey-resolver, but the situation is much more complicated, because CHEMSPIDER, PUBCHEM, etc. have dozens of contributors.
I have definitely understanding of data-curation and I know that data-curation is sometimes a work like 'Sherlock Holmes' has done, because experimental parts of publications (and especially NMR-assignments) tends to be cryptic. We have a lot of systems in parallel, everybody doing his/her job seriously, spends a lot of time on data-curation. What we need is not 10, 20, maybe 100 structure repositories - each of it is incomplete (see above). What we really need is ONE SINGLE STRUCTURE REPOSITORY ( we live on only ONE PLANET ! ) - now I also put my kevlar vest on and put 300 feet landmines around my house - we have it, its CAS ! Sorry to say so, but this is the most complete one. When you are interested in a specific structure and you dont find it in Chemspider, emolecules, Pubchem, etc. - what does this answer tell you. It simply tells you, it is not stored - it DOES NOT TELL you, that IT DOES NOT EXIST ! I am quite sure I will be (hopefully only virtually) beaten by the community for this statement, but please keep in mind the relationship between 'new things' (algorithm, data, new procedures, etc.) and 'data-curation' when hosting a large database. The 'curation-effort' doesnt linearly increase with the size of the database - its at least a quadratic relationship.
What we need is ONE, CENTRALIZED place for structures and 'retrieval functionality' (including this inchikey-resolver), which covers the COMPLETE KNOWN CHEMISTRY and NOT hundreds of incomplete and severly overlapping installations. Let me know, when I can put off my kevlar vest ;-))
An example in order to convince that this (highly desirable) curation-process leads to a lot of confusion:
Globostellatic acid F: was drawn with C-O-O-H (hydroperoxide) instead of a carboxyl group in NMRSHIFTDB -> the data went to PUBCHEM ( CID: 15938977 / original NMRSHIFTDB-number was 22047)
Within NMRShiftDB this entry has been corrected: NMRSHIFTDB-number 20093989 and went again to PUBCHEM: CID=11526176
Do a search on PUBCHEM for the name 'globostellatic' - you end up with 2 'globostellatic acid F' structures, one is correct, the other is a hydroperoxide instead of an acid. Its simply applied error-propagation ...... like in school, when you put your eyes into your neighbors work. When you copy it perfectly, you are consistent, but your examination might also be completely wrong, when your neighbor failes. In chemistry we have a more technical term - its called 'citation'.