-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
current correct way to encode the ion series searched for #128
Comments
At some point we tried to combine the ion series with the type of neutral loss. But I don't think this was properly implemented anywhere, or maybe I am wrong? In any case, the problem with this is that the size of the files increases dramatically so this is why this feature for ion annotations is used less and less I think |
Mascot supports ion series with a NL like b* ("b ion-NH3"). The ion series config is a search-level parameter, not specific to whether a peptide has a variable mod. We don't plan to remove this support. If an alternative encoding is specified, that's fine, but please don't remove the obsoleted terms without providing a replacement. |
@javizca - are you possibly mixing this up with the IonType elements in SpectrumIdentificationItem/Fragmentation? I think the main specification document and / or the CV terms need updated so its clear what the current, correct way to do this is? |
We've got three parts that are hard to specifically address because they are named very similarly and refer to the same concept but were created at different times with seemingly different goals.
The mzIdentML schema explicitly says you may supply a term derived from The mzIdentML schema explicitly stays you may supply a term derived from the parent of mzIdentML never explicitly refers to the @colin-combe wants to express that a search used a specific ion series with a neutral gain/loss without reporting the actual fragment ions matched. Since it's a neutral loss on an ion series, at first glance you may want to declare that a new ion series + neutral loss term derived from Relaxing the term repetition restriction means all the information is explicitly stated, but it could lead to huge files if there are many losses to enumerate. Rolling the losses into the CV means you can't express whether your tool used those losses or did something different. Finally, creating a new term means deciding whether you are stating "I looked for some neutral losses" in the search parameters or enumerating for each modified peptide which losses you searched for. I think rolling this into the modification CV is a compromise that everyone can agree makes maintainers happy as it breaks nothing but puts the loss rules somewhere a motivated individual might look (albeit, each CV would have its own way of expressing this). That said, it doesn't let you express if your search engine did something other than follow those rules. Creating a new CV term to say you searched for neutral losses without naming them is of token value. You could say that XML compresses well enough that it doesn't matter if we increase file sizes by a MB for a large file, but that's a matter of scale. |
this is about the case where the loss is independent of a specific modification |
I think it’s unclear what the current correct cv terms to be used for the ion series searched for (including losses) are. See pg 28 of the spec.
There are multiple deprecated / obselete terms, the ones that appear current aren’t members of the parent term that the specification allows in AdditionalSearchParams?
Try looking up “ion series considered in search” in OLS and navigating to something that is neither marked deprecated or obselete.
In other words, what is the current correct replacement for following:
The text was updated successfully, but these errors were encountered: