SS-1: Acceptance Criteria for Diamond

[Sulstice]

Hello,

I was testing my dataset against different validation platforms and it seems like C&1&1&1 is throwing a rejection. I added it to my list because it's defined in the openSMILES as diamond, Page 21.

http://opensmiles.org/opensmiles.pdf

I'm wondering if this should be accepted by the partialSMILES?
`

[baoilleach]

That's a new one on me. Most people would say that SMILES does not support extended structures. I'd love to know any program that reads that as diamond. However, as a general point, it may be that I do not support the "&", so I'll leave this open until I've checked.

[baoilleach]

Just checked the opensmiles.pdf you point to. This is in the "Proposed extensions" section, and so not part of Daylight SMILES.

[Sulstice]

Ah huh, in the proposed section it looks like the reason why it wasn't implemented was because of the & symbol conflicting with R-Groups.

RDKit can process strings like C1=CC=CC=C1(~[*:1]) so it could be better than the ampersand where the ~ is the virtual bond and the * is the virtual particle. The class can be replaced with a corresponding R-Group and we reserve & for materials like they proposed?

What are your thoughts?