MutationTaster: automatic vs score
1
0
Entering edit mode
6.6 years ago
Farrel ▴ 240

Why would I care if the classification into disease vs polymorphism was automatic or not? Wouldn't the probability of the model being correct all that I need?

I am looking at whole exome sequence data in a sample of affected subjects with a rare disease. The sequences were compared to GRCH38.p2 107 and variant files were derived and then run through annovar. I can see that I have two variables related to MutationTaster: MutationTaster_score and MutationTaster_pred.

the score is the probability of the model being correct from 0 to 1
the prediction classifies as four possible predictions:

  1. "A" ("disease_causing_automatic")
  2. "D" ("disease_causing")
  3. "N" ("polymorphism")
  4. "P" ("polymorphism_automatic")

I read http://www.mutationtaster.org/info/documentation.html but am none the wiser.

genome sequence • 4.1k views
ADD COMMENT
1
Entering edit mode
6.6 years ago
Bioaln ▴ 360

Normally, this distinction occurs when there exist entries, manually annotated by a human being, and entries, which are the result of an automated workflow. If this is the case, I suggest you place your bets on the manual thing. (example: SwissProt vs. UniProt - TrEMBL)

ADD COMMENT
0
Entering edit mode

Thanks for orienting me. Here is a hyperlink to illustrate Swiss-Prot vs. TrEMBL.

ADD REPLY
0
Entering edit mode

I found a slideshow online that states exactly the opposite. Look at slide number 10.

Based on the answer by @Bioaln and based on the reference at Swiss-Prot it appears as if Hina Qaiser's slides are not correct. Do you agree or can you disavow me of my misconception.

ADD REPLY
0
Entering edit mode

There remains no problem, I interpret automatic as: well this protein is known to be in interaction etc., this is only semantics imho

ADD REPLY

Login before adding your answer.

Traffic: 1699 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6