Hi,

I am trying to generate a `BED` file following the below steps:

  - Go to human hg19 [UCSC Table   Browser][1]:
   
  - track: UCSC Genes
   
  - table: knownCanonical
   
  - output format: select fields from primary and related tables
   
  - press get output
   
  - select fields from hg19.knownCanonical: chrom, chromStart,
   chromEnd,transcript
   
  - select fields from hg19.kgXref: geneSymbol
   
  - press get output

This BED file does not have the gene `BBS5` in it. I am sure that [this gene do exist][2]

However, when I follow the same steps except selecting the table = `knownGenes` (instead of `knownCanonical`) , I can see `BBS5` gene. The question is why this gene does not appear in the table `knownCanonical`?

Any insights?


  [1]: https://genome.ucsc.edu/cgi-bin/hgTables?command=start
  [2]: https://genome.ucsc.edu/cgi-bin/hgTracks?db=hg19&lastVirtModeType=default&lastVirtModeExtraState=&virtModeType=default&virtMode=0&nonVirtPosition=&position=chr2%3A170336006-170363165&hgsid=713891099_31zRxNpiiVdk8jm3uyF2G0owacoE
Hello Vijay,

What you are observing here with the missing BBS5 entry in the knownCanonical table is an artifact of how that table was created for hg19. If you take a look at the hg19 UCSC Genes description page (http://genome.ucsc.edu/cgi-bin/hgTrackUi?db=hg19&g=knownGene ) we define knownCanonical as the following:

knownCanonical identifies the canonical isoform of each cluster ID, or gene. Generally, this is the longest isoform.

The problem is, however, when two genes have overlapping coordinates, and one of them is entirely within another, the algorithm considers them isoforms and the smaller gene will be missed by knownCanonical. You can see this with BBS5 by going to the following session (http://genome.ucsc.edu/s/Lou/hg19_MLQ1 ). KLHL41 has a transcript with the same start site as BBS5, however, it extends much further. All of the BBS5 transcripts fall within it. If you query the Table Browser for these coordinates you see only KLHL41.

Using coordinates chr2:170,331,250-170,374,046:

> chr2 170366211 170382772 17243 uc002ueu.1 uc002ueu.1 KLHL41

In order to get around this, you can use the complete knownGenes table, or you could also use the knownCanonical table for hg38. For the hg38 assembly (http://genome.ucsc.edu/cgi-bin/hgTrackUi?db=hg38&g=knownGene ) the table was generated differently:

knownCanonical identifies the canonical isoform of each cluster ID or gene using the ENSEMBL gene IDs to define each cluster. The canonical transcript is chosen using the APPRIS principal transcript when available. If no APPRIS tag exists for any transcript associated with the cluster, then a transcript in the BASIC set is chosen. If no BASIC transcript exists, then the longest isoform is used.

This new method did not have the same issue as hg19, as it uses APPRIS tags, then GENCODE sets, and then finally if those are not available the longest isoform. If you convert the region from the session above to hg38 (View in the top bluebar -> In Other Genomes) you will get the following coordinates (chr2:169,474,740-169,517,536), then if you query the position on the knownCanonical table on the Table Browser you get the following results:

> chr2 169479177 169506655 10932 ENST00000295240.7 ENSG00000163093.11
> BBS5
> 
> chr2 169479479 169525922 41682 ENST00000513963.1 ENSG00000251569.1
> AC093899.2
> 
> chr2 169509701 169526262 36897 ENST00000284669.1 ENSG00000239474.6
> KLHL41

