The plugin to calculate additional smiles for molecules or scaffolds could have the possibility to choose, which kind of smiles it should generate. In CDK 1.5 there are four different kinds of smiles (either canonical/non-canonical and chiral/non-chiral in all four combinations). In this case, we will not have to worry about consistency of smiles types, as the choice is then made by the user.
The feature is now partly usable with commit [1b7f2b]. Two things are not satisfying yet:
Related
Commit: [1b7f2b]
Regaring 2:
An AtomContainer, which is converted into a string by MDLV2000Writer and then reconverted into an AtomContainer by MDLReader, loses some of its properties. The property "stereoElements" originally had 1 element, but after the conversions, it is empty.
Maybe someone can comment on this comparison between original file and intermediate conversion string. The only real difference is the "1" in the third line of the original.
Original:
Converted:
Regarding 2:
this seems to be bug outsite the scope of additional smiles generation, or am i wrong? The molecule should exacly match the imported one, but have the properties stripped (because they are converted to MoleculeProperties and are not needed anymore)
Regarding 1:
So why not simply use the dataset information about chirality? We do not need to detect, if there is some real chirality information present in the dataset. Or is this information not accessible to the plugin?
Last edit: Till Schäfer 2016-03-22
Regarding 1:
The information is not accessible in the plugin, yet. We would have to change the signature of the "getSettingsPanel" method and add a dataset argument to it, to retrieve the information. If that is OK, then the check should be easy.
Regarding 2:
Yes, it is a bug outside the plugin. But I also think that we cannot fix it easily. Maybe we should create a bug report for this?
Regarding 1
am i right, that this in a plugin interface change? We should think about not blowing up this interface with arbitrary information. Nevertheless, the chirality information and in more general the dataset metadata seem to be valuable in some cases. Is there anyway to get the propertydefinitions inside a plugin up to this point? this seems to be another quite usefull information provided by the dataset object.
We must be carefull to give a plugin a read-only access to this informaions. A plugin shopuld not be able to alter some dataset attributes.
Any proposed solutions? Additional thoughts? Lets brainstorm a bit more. We should only change this once and not every few releases.
If we change the signature the manual must be adjusted.
Regarding 2
yes, please create another bug report then and mark this bug to depend on the other bug.