Skip to content
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

[Feature Request] Explicit support for DIA results. #37

Open
wfondrie opened this issue Aug 12, 2021 · 0 comments
Open

[Feature Request] Explicit support for DIA results. #37

wfondrie opened this issue Aug 12, 2021 · 0 comments

Comments

@wfondrie
Copy link
Owner

To have truly valid precursor- and peptide-level FDR estimates for data independent acquisition (DIA) results, we need to add support for the peptide competition step described in section 2.4 of the DIAmeter paper.

Roughly, this involves pairing each target peptide with a decoy that generated it, such that they can compete against each other (as in, we retain only the one with the highest score). On the surface this appears easy enough---we could sort the sequences of all of the target and decoy hits then randomly pair those with matching compositions. However, this simplistic strategy will be overly conservative, because in practice we fail to observe many possible decoy peptides.

An alternative approach would be to require a FASTA (or other protein/peptide database) that explicitly defines all of the possible target and decoy peptides in the search space. We could then follow a similar approach as above, or extract the same amino acid indices as a target peptide in its protein context within the corresponding decoy. Unfortunately, either of these approaches could be problematic: In the former, we assume that we have some knowledge as to how decoys were generated (such as excluding terminal amino acids). In the latter, we assume that the user did not shuffle the full protein sequence, but rather peptides with the protein (note that shuffling protein sequences is statistically invalid, but still occurs).

In conclusion, we need to think about the most robust way to implement this.

sambenfredj referenced this issue in msaid-de/mokapot Apr 12, 2023
…to 'develop'

Replace in disk sort with custom merge sort

Closes #37

See merge request msaid/chimerys/mokapot!31
jspaezp pushed a commit to jspaezp/mokapot that referenced this issue Jun 21, 2024
squashed sqlite writer branch

Closes wfondrie#37

See merge request msaid/inferys/mokapot!44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant