Running the EMBO-2023 tutorial in brendanx@nexus:data\Examples\20231113_Barcelona_Course\Tutorial-5-Thursday-Untargeted-DIA-Fragpipe

I found that building a .blib from the resulting .speclib (which currently requires copying it to the diann-output folder and renaming report.tsv to lib.tsv) had many peptide modified sequences with a leading modification:

[+42.01056]A...

This is a format that Skyline does not understand. Though, it distinguishes an n-terminal modification from an n-terminal-amino-acid modification, it is not balanced and offers no obvious matching format for a c-terminal modification.

BlibBuild needs to convert these to:

A[+42.01056]...

As other parsers already do. The current peptides starting with a bracket are unintelligible to Skyline.

What should it do if there is also a mod on the N-terminal AA? Sum the masses?

Most other software AFAIK has not found it necessary to distinguish between a C-terminus mod and a mod on the C-terminal AA. But there is a fairly simple way to add a way to distinguish them: delimit the terminus if the mod is on the terminus, e.g. PEPTIDEK[212] is on the K, PEPTIDEK.[42] or PEPTIDEK-[42] is on the terminus. Should be easier to read in a monospaced font. Presenting one combined mod when the upstream software says there are two mods seems like a loss of information that would be pretty confusing to me (so I'd expect it to confuse users too).

Please start by making it consistent with the way everything has worked for 15 years. Consult other parsers that handle this case.

If you want to post a separate TODO to improve things, you can.

I did this because it is what Ron Beavis did in X! Tandem and he defended it when I questioned it around 2005. I guess I figured if it was good enough for Ron and X! Tandem it would’ve good enough for Skyline.

Possibly time to rethink, but let’s start by fixing what is broken and actually more confusing and damaging to users than the way Skyline has handled n-terminal mods it’s entire existence.