Deprecations

It seems there have been a lot of deprecations recently but I can't find any document listing them all in one place, giving rationales and assisting with migration: that information is scattered all over the Javadocs, which don't provide any rationale at all. Case at point: the deprecation of the search query mode; we are told JChem "will always use the default mode in the future" but not why.

Hi,





Deprecations are necessary time-to-time, so we can develop our API without being restrained by old versions forever.





We do not have a document dedicated to deprecations, but that would be a probably a very long list, and most users only have to deal with a small percentage of these.





We recommend looking at the list of deprecation during compilation (even most IDEs show these), and then checking the API documentation for details.


We think that is the most convenient place to find the instructions. Most of the time these are very simple "Use B instead of A in the future" and do not require lengthy explanations.

Quote:

Case at point: the deprecation of the search query mode; we are told JChem "will always use the default mode in the future" but not why.

The type of the search (e.g. SUBSTRUCTURE / SUPERSTRUCTURE) determines the correct behavior for that search type (the correct internal representation of the molecule), so there is no reason to have this option at all.





If you have further questions about other deprecation, we are glad to answer them too.





Best regards,





Szilard

Quote:

The type of the search (e.g. SUBSTRUCTURE / SUPERSTRUCTURE) determines the correct behavior for that search type (the correct internal representation of the molecule), so there is no reason to have this option at all.

With all due respect you are evading the question. Why wasn't this this true until now? What has changed elsewhere that suddenly an explicit search type does not make sense anymore?

olefevre wrote:

With all due respect you are evading the question. Why wasn't this this true until now? What has changed elsewhere that suddenly an explicit search type does not make sense anymore?

I think there is a misunderstanding here. Please note that no search type has been deprecated. See the apidoc for setQueryMode:





http://www.chemaxon.com/jchem/doc/api/chemaxon/jchem/db/JChemSearch.html#setQueryMode(int)

Quote:

Determines the format how SMILES/SMARTS query strings are interpreted. (As SMILES or SMARTS.) The most significant difference between these two is the treatment of the "H" string in atom expressions (implicit H versus total H count). This setting has effect only if SMILES / SMARTS query String is specified.

The main reason to deprecate this option was to simplify the JChemSearch API to reduce confusion. Users rarely needed to set this option, and


in those rare cases, it is still possible to import the SMILES/SMARTS string into a Molecule object, and pass it directly to JChemSearch.





See, for example:


http://www.chemaxon.com/jchem/doc/api/chemaxon/jchem/db/JChemSearch.html#setQueryStructure(chemaxon.struc.Molecule)





http://www.chemaxon.com/jchem/doc/api/chemaxon/util/MolHandler.html#MolHandler(java.lang.String,%20boolean)


http://www.chemaxon.com/jchem/doc/api/chemaxon/util/MolHandler.html#getMolecule()





Regards,





Szabolcs

No misunderstanding: I meant to write query mode, not query type, but I tripped. OK. so it's just an API simplification. However this document: http://www.daylight.com/meetings/emug00/Sayle/substruct.html contains an example (§ 5) where the same string has radically different interpretations as a SMILES vs. a SMARTS string. I am not a chemist but that doesn't look so innocuous...

I agree with you. (The above mentioned H property is more serious, I think. For example [CH4] matches any carbon atom when interpreted as smiles, and only matches isolated methane fragments when interpreted as SMARTS.)





It is best to use a molecular format that has no ambiguity in interpreting query features. We recommend the .mrv format to communicate between the query-drawing Marvin Sketch and the search engine, because it is unambiguous and can represent all query features that Marvin and JChem understands. For other sketchers, it is best to use the mol format.





Szabolcs

I have a question about SMILES vs. SMARTS that has been gnawing at me for a long time: is SMARTS syntactically (semantically I understand it is simply a different beast) a strict superset of SMILES? Because, e.g., in MolHandler you have a flag to force a would-be SMILES string to be treated as a SMARTS instead but you don't have a flag to specify SMILES or SMARTS explicitly, which is what I would have expected. Your flag only makes sense if all SMILES strings can be seen as SMARTS strings but not vice-versa.





My problem with MRV is that it's way too verbose for humans: it is fine as an exchange format behind the scenes but if someone wants to write a short query by hand as text he is not going to use MRV: he'll write it as a SMILES/SMARTS.

olefevre wrote:

I have a question about SMILES vs. SMARTS that has been gnawing at me for a long time: is SMARTS syntactically (semantically I understand it is simply a different beast) a strict superset of SMILES?

Yes. All SMILES strings are also valid SMARTS strings.

olefevre wrote:

Because, e.g., in MolHandler you have a flag to force a would-be SMILES string to be treated as a SMARTS instead but you don't have a flag to specify SMILES or SMARTS explicitly, which is what I would have expected. Your flag only makes sense if all SMILES strings can be seen as SMARTS strings but not vice-versa.

This is the case. When you use SMILES import (query mode=off), and your string still contains a SMARTS-only feature, then it will be interpreted as SMARTS automatically. The option is only useful if the input can be interpreted both as SMILES and SMARTS.

olefevre wrote:

My problem with MRV is that it's way too verbose for humans: it is fine as an exchange format behind the scenes but if someone wants to write a short query by hand as text he is not going to use MRV: he'll write it as a SMILES/SMARTS.

Yes, it may be ideal for you, but it takes deep cheminformatics literacy to write SMILES/SMARTS by hand. :) Most chemists didn't hear about these formats, because it is(was) not part of their training at uni.





Szabolcs

OK. Thanks a lot for all the explanations.