SEP 033: Concrete descriptions of non-canonical DNA, RNA, and proteins

[jonrkarr]

Full details in the pull request, in the file https://github.com/SynBioDex/SEPs/blob/master/sep_033.md

[jakebeal]

@jonrkarr In theory, supporting BpForms seems pretty straight-forward to me --- it's just another textual sequence format.

Some things about the recommended implementation in the SEP are not clear to me, however:

• Is the recommendation to add BpForms as an optional format or to replace IUPAC as the recommended format?
• The SEP recommends incorporating the BpForms library into SBOL libraries. BpForms appears to be only available in Python currently, but SBOL libraries are available in multiple languages (Java, Python, C++, Javascript, F#). How do you recommend navigating this issue?

[jonrkarr]

Jake, thanks for the clarifying questions. I'll revise the SEP to try to address these questions.

• Yes, the proposal is to add BpForms as a recommended encoding for non-canonical DNA, RNA, and proteins. More concretely, the proposal is simply to add BpForms to Table 1 of the SBOL specification.

  Although BpForms can represent any IUPAC sequence, because BpForms is, at least not yet, a standard, we are not recommending replacing IUPAC with BpForms. Allowing both IUPAC and BpForms would allow SBOL to continue to support the existing users, as well as accommodate users who require more chemical information and precision.

• The proposal is simply to add BpForms to Table 1 of the SBOL specification.

  Going forward, I think it would be useful to incorporate the capabilities to describe and validate non-canonical DNA, RNA, and proteins more directly into SBOL/libSBOL. One potential way is to incorporate the BpForms software into each flavor of libSBOL. Another potential way is to encode non-canonical DNA, RNA, and proteins into RDF. Because there are multiple ways to achieve this, I think this is something that the community should discuss. Until this time, users who need to capture more chemical detail could use the BpForms encoding. This would allow users to begin to explore use cases which require more chemical information, which could anchor discussion about how SBOL should proceed.

  Although I think it would be helpful to incorporate the interpretation of BpForms and the other encodings (SMILES, IUPAC, IUBMB) into libSBOL (e.g., this would enable verification of encoded strings), I am also not recommending incorporating the BpForms software into libSBOL at this time because libSBOL does not have currently the ability to interpret the other sequence encodings. To follow this separation, the BpForms software should remain separate from libSBOL.

[jakebeal]

Thanks: this clarification is very helpful.

If we're going to support adding BpForms to Table 1, then we'll definitely need to have some form of support for dealing with BpForms in the SBOL libraries. The full BpForms library might not be necessary, but a number of library operations depend on the ability to reason about locations in sequence strings, e.g., to annotate a location, to check if a sub-component is correctly aligned, or to compose sequences together (in ways more complex than just concatenating).

If I understand correctly, BpForms does not have a 1-to-1 alignment between string index and sequence location. Is there a simple way of computing locations in BpForms, or does that require a significant amount of the BpForms library code?

[jonrkarr]

Correct, there is no one-to-one alignment between string indices and sequence locations. This is also true of SMILES. However, the alignment is simple (the monomer indices increase from left to right as in IUPAC). We can provide a function to compute locations which could be incorporate into libSBOL. This just requires counting the number of single characters, square brackets, and curly brackets. This can be done without fully interpreting encoded sequences with the BpForms library.

As an aside, the SMILES situation is more complicated because there are multiple versions of SMILES. Different software assign different numbers to atoms when they interpret SMILES. For example OpenBabel and Marvin assign different atoms numbers for dGMP (OC1CC(OC1COP(=O)([O-])[O-])n1cnc2c1nc(N)[nH]c2=O). In BpForms, we deal with this by specifying that the atom numbers are in the basis established by OpenBabel.

[cjmyers]

I'm not concerned about the one-to-one alignment issue. Our libraries do already allow for SMILES which Jonathan points out does not have this. We only require this for IUPAC sequences, so we could continue to do so. Indeed, I would expect each object to still have an IUPAC sequence. The BpForms sequence if provided would be added information. I would though want the libraries to at least be able to tell if the BpForms encoded string was syntactically correct. libSBOLj at least does this for SMILES. I'm not sure if the other libraries due, but for validation I would want to have this ability at least. Do you have a grammar file? Or could you provide a java library that we could link to that would validate the syntax?

…

On Jul 15, 2019, at 9:03 PM, Jonathan Karr ***@***.*** ***@***.***>> wrote: Correct, there is no one-to-one alignment between string indices and sequence locations. This is also true of SMILES. However, the alignment is simple (the monomer indices increase from left to right as in IUPAC). We can provide a function to compute locations which could be incorporate into libSBOL. This just requires counting the number of single characters, square brackets, and curly brackets. This can be done without fully interpreting encoded sequences with the BpForms library. As an aside, the SMILES situation is more complicated because there are multiple versions of SMILES. Different software assign different numbers to atoms when they interpret SMILES. For example OpenBabel and Marvin assign different atoms numbers for dGMP (OC1CC(OC1COP(=O)([O-])[O-])n1cnc2c1nc(N)[nH]c2=O). In BpForms, we deal with this by specifying that the atom numbers are in the basis established by OpenBabel. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#77?email_source=notifications&email_token=AA2YH523RAWQIKNOPYPR7ELP7TCXRA5CNFSM4H2HWWLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ6VA2Q#issuecomment-511529066>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2YH5Y5VJ5Y7435TKDZBFTP7TCXRANCNFSM4H2HWWLA>.

[jonrkarr]

It seems like the encodings need to have well-defined locations, which BpForms does. BpForms uses the same location conventions as IUPAC and SMILES. These are also fairly human-readable as the locations increase monotonically from left to right. Yes, there's a grammar. FYI, there's a few more sophisticated validations that aren't encoded in the grammar. For example, verifying that 5' caps only appear at the last position. SMILES has the same issue -- it is possible to encode molecules in SMILES that are not physically realistic. I think grammar validation would be a good start. Ideally, validation would go further to verify that the encoded molecules are realistic.

…

On Mon, Jul 15, 2019 at 3:55 PM cjmyers ***@***.***> wrote: I'm not concerned about the one-to-one alignment issue. Our libraries do already allow for SMILES which Jonathan points out does not have this. We only require this for IUPAC sequences, so we could continue to do so. Indeed, I would expect each object to still have an IUPAC sequence. The BpForms sequence if provided would be added information. I would though want the libraries to at least be able to tell if the BpForms encoded string was syntactically correct. libSBOLj at least does this for SMILES. I'm not sure if the other libraries due, but for validation I would want to have this ability at least. Do you have a grammar file? Or could you provide a java library that we could link to that would validate the syntax? > On Jul 15, 2019, at 9:03 PM, Jonathan Karr ***@***.*** ***@***.***>> wrote: > > Correct, there is no one-to-one alignment between string indices and sequence locations. This is also true of SMILES. However, the alignment is simple (the monomer indices increase from left to right as in IUPAC). We can provide a function to compute locations which could be incorporate into libSBOL. This just requires counting the number of single characters, square brackets, and curly brackets. This can be done without fully interpreting encoded sequences with the BpForms library. > > As an aside, the SMILES situation is more complicated because there are multiple versions of SMILES. Different software assign different numbers to atoms when they interpret SMILES. For example OpenBabel and Marvin assign different atoms numbers for dGMP (OC1CC(OC1COP(=O)([O-])[O-])n1cnc2c1nc(N)[nH]c2=O). In BpForms, we deal with this by specifying that the atom numbers are in the basis established by OpenBabel. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub < #77?email_source=notifications&email_token=AA2YH523RAWQIKNOPYPR7ELP7TCXRA5CNFSM4H2HWWLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ6VA2Q#issuecomment-511529066>, or mute the thread < https://github.com/notifications/unsubscribe-auth/AA2YH5Y5VJ5Y7435TKDZBFTP7TCXRANCNFSM4H2HWWLA >. > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#77?email_source=notifications&email_token=AAVXMKOO2MTKO6X5PJWFGKTP7TI2JA5CNFSM4H2HWWLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ6ZDLY#issuecomment-511545775>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAVXMKL4AAQ3R4ZLKMQQZGLP7TI2JANCNFSM4H2HWWLA> .

[jonrkarr]

I updated the SEP to clarify these questions. See PR #83.

[cjmyers]

Sounds good to me. Do you have a Java library that we can use for this? Chris

…

On Jul 15, 2019, at 10:17 PM, Jonathan Karr ***@***.***> wrote: It seems like the encodings need to have well-defined locations, which BpForms does. BpForms uses the same location conventions as IUPAC and SMILES. These are also fairly human-readable as the locations increase monotonically from left to right. Yes, there's a grammar. FYI, there's a few more sophisticated validations that aren't encoded in the grammar. For example, verifying that 5' caps only appear at the last position. SMILES has the same issue -- it is possible to encode molecules in SMILES that are not physically realistic. I think grammar validation would be a good start. Ideally, validation would go further to verify that the encoded molecules are realistic. On Mon, Jul 15, 2019 at 3:55 PM cjmyers ***@***.***> wrote: > I'm not concerned about the one-to-one alignment issue. Our libraries do > already allow for SMILES which Jonathan points out does not have this. We > only require this for IUPAC sequences, so we could continue to do so. > Indeed, I would expect each object to still have an IUPAC sequence. The > BpForms sequence if provided would be added information. > > I would though want the libraries to at least be able to tell if the > BpForms encoded string was syntactically correct. libSBOLj at least does > this for SMILES. I'm not sure if the other libraries due, but for > validation I would want to have this ability at least. Do you have a > grammar file? Or could you provide a java library that we could link to > that would validate the syntax? > > > On Jul 15, 2019, at 9:03 PM, Jonathan Karr ***@***.*** > ***@***.***>> wrote: > > > > Correct, there is no one-to-one alignment between string indices and > sequence locations. This is also true of SMILES. However, the alignment is > simple (the monomer indices increase from left to right as in IUPAC). We > can provide a function to compute locations which could be incorporate into > libSBOL. This just requires counting the number of single characters, > square brackets, and curly brackets. This can be done without fully > interpreting encoded sequences with the BpForms library. > > > > As an aside, the SMILES situation is more complicated because there are > multiple versions of SMILES. Different software assign different numbers to > atoms when they interpret SMILES. For example OpenBabel and Marvin assign > different atoms numbers for dGMP > (OC1CC(OC1COP(=O)([O-])[O-])n1cnc2c1nc(N)[nH]c2=O). In BpForms, we deal > with this by specifying that the atom numbers are in the basis established > by OpenBabel. > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub < > #77?email_source=notifications&email_token=AA2YH523RAWQIKNOPYPR7ELP7TCXRA5CNFSM4H2HWWLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ6VA2Q#issuecomment-511529066>, > or mute the thread < > https://github.com/notifications/unsubscribe-auth/AA2YH5Y5VJ5Y7435TKDZBFTP7TCXRANCNFSM4H2HWWLA > >. > > > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#77?email_source=notifications&email_token=AAVXMKOO2MTKO6X5PJWFGKTP7TI2JA5CNFSM4H2HWWLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ6ZDLY#issuecomment-511545775>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAVXMKL4AAQ3R4ZLKMQQZGLP7TI2JANCNFSM4H2HWWLA> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#77?email_source=notifications&email_token=AA2YH5ZTZ5IU6DAGI3GSEJDP7TLPJA5CNFSM4H2HWWLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ63AFA#issuecomment-511553556>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA2YH5ZASN6IHVYY4K6RGRTP7TLPJANCNFSM4H2HWWLA>.

[jonrkarr]

The grammar is written for Lark in EBNF (with a few slight modifications described here).

We plan to make a more standard version of the grammar that can be used with other parser generators. I think this will only require a few small changes. There are several parser generators for C, C++, Java, Python, etc. that support EBNF such as:

• ANTLR
• Beaver
• Coco/R
• Grammatica
• JavaCC
• UniCC

If you have a preferred library, we can target that.