Interpreting the results

Once the search performed you will be able to navigate the database through five different types of pages:

• The browser
• A gene page (or "gene-centric view", default result page from gene search)
• A transcript page (or "transcript-centric view", default result page from transcript search)
• An ORF page (or "ORF-centric view")
• A locus page (default result page from locus search)

Each of these page is decribed below.

Filtering the results

On each view, the results can be filtered opening the menu located on the left side of the page.

Filtering the results

Several types of filters are common to all four pages (gene, transcript, ORF and locus pages) whilst some other may be specific to some pages. These filters are described below.

When several filters of the same type (e.g. Cell type HEK293 and Cell type HeLa) are selected at the same time, all the entries matching at least one of the condition will be selected (the operation performed is equivalent to an union).
When several type of filters (e.g. Cell type HEK293 and ORF annotation Upstream) are selected at the same time, only entries matching all the criteria will be selected (the operation performed is equivalent to an intersection).

• Identification method: This filter allows to select exclusively the ORFs that were detected with the identification method(s) selected with the filter. See the the advanced documentation section dedicated to the data sources for more information about the methods registered. If several identification methods are selected, all entries matching at least one of the criteria will be displayed.
• Start codon: This filter allows to select the ORFs with a particular start codon. Three nucleotides must be provided respecting the standard IUB/IUPAC nucleic acid codes (A, T, G, C, N allowed). Lower-case letters are accepted and are mapped into upper-case. The following wildcards may replace one or several of the nucleotides:
  • N for any base (A/T/G/C)
  • W for weak (A/T)
  • S for strong (G/C)
  • R for purines (G/A)
  • Y for pyrimidine (T/C)
  • K for keto (G,T)
  • M for amino (A/C)
  • B for G/T/C
  • D for G/A/T
  • H for A/C/T
  • V for G/C/A
• Kozak context: This filter allows to select the ORFs located on transcripts where their Kozak context matches the one selected. the advanced documentation section dedicated to the data sources for more information about the Kozak contexts definitions. If several contexts are selected, all entries matching at least one of the criteria will be displayed.
• ORF length: This filter allows to select the ORFs within a specific range of size. A minimal or a maximal size or both of them can be provided to filter the results. The filter uses the Genomic lengths of the ORFs, defined as the sum of the lengths (in bp) of each exon constituting the ORF (thus excluding its eventual introns) and including both the start and the stop codons. The ORFs that equals the minimal and / or the maximal value provided will be selected.
• Transcript biotype: The filters of this section allow to select the ORFs located on one (or several) specific transcript biotypes. Biotype definitions may be found on the Ensembl website. If several biotypes are selected, all entries matching at least one of the criteria will be displayed.
• ORF annotations: The filters of this section allow to select the ORFs annotated in a particular category (short, upstream...). Four categories of annotations are defined depending on the criteria used by our algorithm to perform the annotation: length, biotype, relative position and reading frame. Please see the section of the advanced documentation dedicated to the ORF annotations for more details regarding the nomenclature we use. If several annotations of the same category are selected (e.g. Upstream and Overlaping), all entries matching at least one of the criteria will be displayed. If several annotations of different categories are selected (e.g. Upstream and sORF), all entries matching all the criteria will be displayed.
• Cell types: The filters of this section allow to select the ORFs that have been identified in some particular cell types. Here, a cell type can actually be a cell line, a tissue, an organ or eventually a sample from tissue or organ under pathological condition, depending on the information provided in the original data sources. If several cell types are selected, all entries matching at least one of the criteria will be displayed.

To confirm your selection click on the Filter button. The Restart button allows to reset all the changes that have been recently applied on the filters (i.e. since the last load of the page). The Clear button will delete all the filter selected. When one of these button is used, it is then necessary to refresh the page using the Filter button to get the appropriate results. When a page is loaded for the first time, there are obviously no filters applied.

Exporting the results

The four pages allow to export results of your researches at CSV, FASTA and BED formats. These formats and the data they contain are detailed in this section. Please note that the preparation of the file to download may take some time if you are displaying a large set of data on the browser.

Exporting the results

Data sources

Data from computational predictions, ribosome profiling experiments and mass spectrometry expriments (peptidomics, proteomics, proteogenomics) have been integrated in the database.

The following data sources have been integrated in the database:

The following data set from sORFs.org original datasets for H.sapiens (46 datasets): andreev_2015, cenik_2015, eichorn_2014, ingolia_2014, iwasaki_2016, jan_2014, park_2016, park_2017, werner_2015, zur_2016, calviello_2016, elkon_2015, fritsch_2012, ingolia_2012, jakobsson_2017, liu_Hela_2013, loayza_puch_2013, loayza_puch_2016, malecki_2017, mills_2016, niu_2014, rooijers_2013, rubio_2014, sidrauski_2015, tanenbaum_2015, tirosh_2015, wang_2015, xu_2016, wiita_2013, liu_HEK_2013, gawron_2016, rutkowski_2015, gonzalez_2014, guo_2014, yoon_2014, crappe_2014, zhang_2017, stern_ginossar_2012, stumpf_2013, ji_BJ_2015, lee_2012, su_2015, shi_2017, ji_breast_2015, wein_2014, grow_2015.

The following data set from sORFs.org original datasets for M.musculus (27 datasets): blanco_2016, cho_2015, castaneda_2014, eichorn_bcell_2014, laguesse_2015, deklerck_2015, gerashchenko_2016, hurt_2013, ingolia_2014_mmu, katz_2014, reid_2014, reid_er_2016, thoreen_2012, eichorn_liver_2014, gonzalez_2014_mmu, guo_2010_mmu, diaz_munoz_2015, eichorn_3t3_2014, janich_2015, you_2015, reid_cytosol_2016, jovanovic_2015, gao_mef_2014, fields_2015, ingolia_2011, gao_liver_2014, lee_2012_mmu.

The original IDs may be used to access the entries in the original datasets / databases. As some sources were not providing any ORF IDs, you may find here the IDs we used as "original IDs" for each data source:

• Erhard2018: The "original" IDs look like index_chr:start-stop:strand, where index is the line number of the entry in the original file, chr is the chromosome name (with the 'chr' prefix), start, stop and strand are respectively the ORF start and stop location and the ORF strand in the original annotation version.
• Johnstone2016: The original ID used is the one registered in the column orfID of the data source.
• Laumont2016: The "original" IDs look like index_chr:start-stop:strand, where index is the line number of the entry in the original file, chr is the chromosome name (with the 'chr' prefix), start, stop and strand are respectively the ORF start and stop location and the ORF strand in the original annotation version.
• Mackowiak2015: The original ID used is the one registered in the column orfID of the data source.
• Samandi2017: The original ID used is the one registered in the column Protein accession of the data source.
• sORFs_org_Human: The original ID used is the one registered in the column Sorf ID of the data source and corresponds to the unique ID used on sORFs.org.
• sORFs_org_Mouse: The original ID used is the one registered in the column sORF ID of the data source and corresponds to the unique ID used on sORFs.org.

ORF annotations

Despite the use of a common nomenclature by the majority of the data sources to describe the ORFs, no clear consensus regarding the definitions of these categories or their names has been defined so far. Hence, in order to get common definitions of ORF annotations for all the entries, the ORF annotations has been defined according to five main classes of criteria: the ORF length, the RNA biotype, the position of the ORF on the transcript relatively to the canonical CDS, the reading frame and the ORF strand.

• ORF annotations based on length
  • sORF (short ORF): The ORF sequence is shorter than 100 amino acids (stop codon and intron excluded).
• ORF annotations based on the transcript biotype
  • Intergenic: The ORF is located on a 'Long intergenic ncRNA' or 'lincRNA' biotype.
  • ncRNA: The ORF is located on a 'Non coding', 'ncRNA', 'Processed transcript', 'processed_transcript', 'Long non-coding RNA', 'lncRNA', '3' overlapping ncRNA', 'Macro lncRNA', 'Long intergenic ncRNA', 'lincRNA', 'miRNA', 'miscRNA', 'piRNA', 'rRNA', 'siRNA', 'snRNA', 'snoRNA', 'tRNA', or 'vaultRNA' biotype.
  • Pseudogene: The ORF is located on a 'Pseudogene', 'IG pseudogene', 'Polymorphic pseudogene', 'Processed pseudogene', 'processed_pseudogene', 'Transcribed pseudogene', 'transcribed_processed_pseudogene', 'transcribed_unprocessed_pseudogene', 'unprocessed_pseudogene', 'transcribed_unitary_pseudogene', 'Translated pseudogene', 'Unitary pseudogene', 'unitary_pseudogene' or 'Unprocessed pseudogene' biotype.
  • NMD: The ORF is located on a 'Non sense mediated decay', 'NMD', 'nonsense_mediated_decay' or 'non_stop_decay' biotype.
  • Readthrough: The ORF is located on a 'Readthrough' or 'Stop codon readthrough' biotype.
• ORF annotations based on the relative position
  • Upstream: The start codon of the ORF is located upstream of the CDS start codon and the stop codon of the ORF is located upstream of the CDS stop codon. Note that if both the start and the stop codons are the same for the ORF than the CDS, then the ORF is annotated CDS instead.
  • Downstream:
    • The start codon of the ORF is located downstream of the CDS start codon and the stop codon of the ORF is located downstream of the CDS stop codon. Note that if both the start and the stop codons are the same for the ORF than the CDS, then the ORF is annotated CDS instead, or
    • The ORF is located on a '3'overlapping ncRNA' biotype.
  • Overlapping:
    • The start codon of the ORF is located upstream of the CDS start codon and the stop codon of the ORF is located downstream of the CDS start codon and upstream of the CDS stop codon, or
    • The start codon of the ORF is located downstream of the CDS start codon and upstream of the CDS stop codon and the stop codon of the ORF is located downstream of the CDS stop codon or
    • The ORF is located on an 'Antisense' biotype.
  • Intronic: The ORF is located on a 'retained_intron', 'sense_intronic' or 'sense_overlapping' biotype.
  • InCDS: The start codon of the ORF is located downstream of the CDS start codon and the stop codon of the ORF is located upstream of the CDS stop codon. Note that if both the start and the stop codons are the same for the ORF than the CDS, then the ORF is annotated CDS instead.
  • CDS: The start codon of the ORF is the same than the CDS start codon and the stop codon of the ORF is the same than the CDS stop codon.
  • NewCDS: The start codon of the ORF is located upstream of the CDS start codon and the stop codon of the ORF is located downstream of the CDS stop codon. Note that if both the start and the stop codons are the same for the ORF than the CDS, then the ORF is annotated CDS instead.
• ORF annotations based on the reading frame
  • Alternative: The ORF start is located on a different frame than the CDS start codon (i.e. the distances in bp between the first nucleotide of the ORF start and the first nucleotide of the CDS start is not a multiple of three).
• ORF annotations based on the strand
  • Opposite: The ORF is located on the opposite strand of its transcript.

Cell types

Original data sources do not use a common thesaurus or ontology to name the cell types (e.g. 'HFF' and 'Human Foreskin Fibroblast') or may use non-biological meaning names (e.g. sORFs.org provides the name of the original publication as a cell type). In order to provide an uniform informative naming, we manually recovered the name of the cell line, tissue or organ used in these datasets and defined an unique name to be used in MetamORF for each cell line, tissue or organ. In addition, when feasible, we recovered the ontology terms matching the cell line, tissue or organ in the following ontologies:

All the cell types existing in MetamORF may be accessed through the cell type browser. The pages of the cell types provide a short description of the cell type as well as the ontology terms matching with it. From these pages, it is also possible to browse all the ORFs identified in the cell type in H.sapiens and/or M.musculus.

Example of the page describing the HeLa cells

Kozak contexts definition

Kozak contexts have been assessed using the criteria defined by Hernandez et al., Trends in Biochemical Sciences, 2019 (doi: 10.1016/j.tibs.2019.07.001). To annotate the Kozak contexts, the nucleotides located from the -6 to +4 positions around the start codon (where +1 position correspond to the position of the first nucleotide of the start codon) have been downloaded from Ensembl for each existing ORF - transcript association. Then, the start flanking sequence has been compared to four patterns defining optimal, strong, moderate and weak Kozak contexts.
Kozak contexts have been assessed even for the ORFs using alternative start codons (i.e. start codons different from ATG), looking for the same patterns around the start codon. Hence, if you are willing to display exclusively the ORFs with 'strict' optimal Kozak context, you must use the 'optimal' filter and the 'ATG' start codon filter at the same time.

The following patterns have been used to identify the start codons:

With R = A/G (purine), Y = C/T (pyrimidine).

From a technical point of view, the following regular expression have been used to perform the Kozak context assessment:

Build URLs to MetamORF

If you are willing to include hyperlinks to MetamORF in your documents (reports, website...), you may build the URLs using the following rules:

• To point out to a gene page, use http://metamorf.hb.univ-amu.fr/gene/{species}/{id}, where {species} is the name of the species (either hsapiens or mmusculus), and {id} is the gene ID, symbol or alias.
• To point out to a transcript page, use http://metamorf.hb.univ-amu.fr/transcript/{species}/{id}, where {species} is the name of the species (either hsapiens or mmusculus), and {id} is the transcript official ID, name or MetamORF transcript ID.
• To point out to an ORF page, use http://metamorf.hb.univ-amu.fr/ORF/{species}/{id}, where {species} is the name of the species (either hsapiens or mmusculus), and {id} is the MetamORF ORF ID.
• To point out to a locus page, use http://metamorf.hb.univ-amu.fr/locus/{species}/{chr}:{start}-{end}/{strand}, where {species} is the name of the species (either hsapiens or mmusculus), {chr} is the name of the chromosome (with the 'chr' prefix), {start} and {end} are respectively the lower and upper bound of the locus of interest. The {strand} parameter is optional and may take as value '+', '-' or 'NA'.

Database schema

Database schema are available on request, please contact us if you need them.

Statistical description of the databases

Advanced statistical description of the databases are available on request at the .tar.gz format. The archive contains both html and png files generated with R and Rmd. Please be aware that these files includes technical information and a good knowledge of the database structure is required to interpret all the statistics described there. Please contact us if you are willing to get this archive.

RqueryORF package

A R package has been implemented to handle connections to the database and build some data frames summurazing the information contained in MetamORF. This package intends to be used to perform large queries on the databases and requires a good knowledge of the structure we used.
As this package is still under development, it is not yet available on the CRAN nor GitHub. Large queries cannot yet be performed through our web interface, so please feel free to contact us if you need to perform such queries.

Workflow used to build the database

Please see our publications for detailed material and methods. If you need information regarding technical details related to the build of the database and source code implemented, please contact us.

Source code

The source code used to build the database and its documentation are available on GitHub.

Get the full database

You may download the content of the full database at FASTA and BED formats on this page. If you are willing to get a copy of the full database at MySQL format, please contact us.

MetamORF softwares and languages

The pipeline used to build MetamORF has been developed using Python (v2.7) with SQLAlchemy ORM (sqlalchemy.org, v1.3.5). The database has been handled using MySQL (mysql.com, v8.0.16). Docker (docker.com, v18.09.3) and Singularity (singularity.lbl.gov, v2.5.1) environments have been used in order to ensure reproducibility and to facilitate deployment on high-performance clusters (HPCs).

The current web interface has been developed using the Laravel (laravel.com, v7.14.1) framework with PHP (v7.3.0), JavaScript 9, HTML 5 and CSS 3. NGINX (v1.17.10) web server and PHP server (v7.3.0) were deployed with Docker (docker.com, v18.09.3) and Docker-compose (v1.24.0) to ensure stability.

Web browser compatibility

The web interfaced has been tested with the following browsers.

Database releases

• 1.0: First release of the database. Published on 01/07/2020.

UCSC Genome Browser

Ensembl Track Hub

New to Track Hubs?

If you do not kown what a Track Hub is, please check the UCSC Track Hub documentation. Briefly, Track Hubs are web-accessible directories of genomic data that can be viewed on Genome Browsers. It offers a convenient way to view and share very large sets of data. The track hub utility allows efficient access to data sets from around the world through the familiar Genome Browser interfaces.
We advice to read the UCSC Track Hub paper, Raney BJ, et al. Track Data Hubs enable visualization of user-defined genome-wide annotations on the UCSC Genome Browser. Bioinformatics. 2014 Apr 1;30(7):1003-5.
If Ensembl is your favorite Genome Browser, you may find a tutorial here.

MetamORF Genome tracks and Track Hub

MetamORF Track Hub URL: http://metamorf.hb.univ-amu.fr/hubDirectory/hub.txt.

Track Hubs may sometimes experience limitations on large regions due to the high volume of data. In such cases, it may be interesting to download yourself MetamORF BED files and upload them on your favorite Genome Browser (UCSC, IGV, e!...). To download these files, please check the downloads page.

• In my results, there is a transcript which official ID is UNKNOWN TRANSCRIPT, what does that mean?
• Why does my gene has two aliases nearly identical, with one of them having a OFF: prefix?
• Why I am not able to find any gene when I search using a HGNC or a NCBI ID?
• My ORF seems to be related to several genes. How is that possible?
• The transcript I am looking seems to be related to another gene than the one described on Ensembl or NCBI website. Which database should I trust?
• It seems that the ORF I am looking at is related to a gene with an unusual name. What happened?
• How are registered mitochondrial and sexual chromosomes in MetamORF?
• Which genome annotations are you using in your database?
• I am confused about the start and stop (or end) coordinates? Why are stop and end coordinates always higher than the start coordinates, even for ORFs or transcripts located on the reverse strand?
• To which nucleotides are actually corresponding the start, stop and end positions?
• I am confused about the absolute coordinates? What coordinate counting system do you use?
• What are the difference between absolute and relative coordinates? Why are the relative coordinates sometimes missing? Which ones should I use?
• What is the difference between an ORF and a CDS?
• What are the nucleotides included in the flanking sequences around the start codon?
• According to you MetamORF contain unique entries. Still, when I am looking at data in a genome browser it seems that a lot of ORFs are similar. How is that possible?
• I have data about sORFs that might be of interest for your database. How can I submit data to be included in MetamORF?
• MetamORF web interface is not working fine. I found information that seems to be inaccurate in your database. I have a question that is not treated in you FAQ.
• How should I cite MetamORF?

In my results, there is a transcript which official ID is UNKNOWN TRANSCRIPT, what does that mean?

When we integrated the data from the data sources, information about the transcript were sometimes missing, either for the whole source or only for some of the ORFs. In such cases the ORF was considered as located on an 'unknown' transcript. Hence all ORFs related to the same gene and for which transcript is unknown are grouped together on the a transcript with the UNKNOWN TRANSCRIPT ID.
Each of the 'unknown transcripts' have a different MetamORF unique ID as soon as they are related to different genes. Note that searching for 'unknown transcripts' from the search page is not allowed as there are two many transcript with this ID in our database. We suggest to use one of the other search mode (gene, locus, ORF) and then click on this transcript if you need to access to the transcript page or to use its MetamORF ID to perform the search. By definition, these transcripts are obviously missing all information (start, end, strand, CDS...) and any ORF located on a known transcript will not appear on the unknown transcript.

Why does my gene has two aliases nearly identical, with one of them having a OFF: prefix?

During the build of MetamORF, we started by importing the cross-references from HGNC, MGI, NCBI and/or Ensembl databases. Genes usually have an alias considered as official (e.g. the official alias of 'GADD34' is 'PPP1R15A'). The alias known as the official alias is preceeded by the OFF: prefix in order to be identified more easily.

Why I am not able to find any gene when I search using a HGNC or a NCBI ID?

When performing you search, HGNC IDs must be preceed by the HGNC: prefix and NCBI IDs must be preceed by the NCBI: prefix, in order to avoid any confusion in external references. As Ensembl ID can be easily recognized, this is not necessary to add any prefix to them. Symbols, names and aliases being idependent to these resources, they have to be provided without any prefix.

My ORF seems to be related to several genes. How is that possible?

In ORF pages, it may happen that an ORF is related to several genes. This may happen when the same ORF was reported by two different data sources which were using different gene ID, name or alias, that are supposed to design the same gene but unknown by MetamORF. Because one of the cross-reference was missing from MetamORF, it was not able to detect that the gene was actually the same, and the ORF has thus been related to distinct genes.

The transcript I am looking seems to be related to another gene than the one described on Ensembl or NCBI website. Which database should I trust?

When integrating data from the original sources, MetamORF kept the relationship between the transcripts and the gene provided by the data source. Hence, if for some reason the relationship provided by the data source was not accurate, the relationship registered in MetamORF may be wrong, and a transcript may have been inaccurately associated to a gene.
In addition, when the transcript information was provided but the gene ID was missing, MetamORF tried to recover the gene information from the transcript ID by querying Ensembl database. If for some reason, the gene name recovered was inaccurate (due to versionning issues for instance), then again the relationship registered in MetamORF can be wrong.
Finally, it may happen that some gene aliases are refering to two distinct genes (e.g. RUFY3 refers to both 'RUFY3' and 'FYCO1' genes). When this happened, MetamORF tried to look for the gene which had the provided alias as official alias (in this example, it would have associated RUFY3 to the actual RUFY3 gene, i.e. the gene with Ensembl ID 'ENSG00000018189'). If the transcript was actually related to the other gene (in this example, 'FYCO1'), then MetamORF will associate it by mistake with the wrong gene ('RUFY3' in our example).
Hence, due to these various issues, it may be highly difficult to find the origin of the bad association. We suggest in such cases to trust the Ensembl or NCBI databases as the mistake is susceptible to have been introduced during the processing of data, either by the original data source or by MetamORF workflow.

It seems that the ORF I am looking at is related to a gene with an unusual name. What happened?

Sometimes, information about the gene was missing from the data source. In such cases, we tried to recover it from the transcript ID, or (when it was not provided) from the ORF coordinates. It may happen that the ORF coordinates were found ovelapping with several genes on the same strand or no gene. In such case the ORF was registered as related with an 'unknown' genes. Contrary to 'unknown' transcripts, 'unknown' genes are using different names. The following nomenclature is used:

• OVERLAPPING_GENES_gene1_gene2 gene ID is used for ORFs located in a locus overlapping exactly two genes (gene1 and gene2).
• OVERLAPPING_GENES_gene1_to_gene2 gene ID is used for ORFs located in a locus overlapping at least three genes (the name of the two genes are the one located at extremal positions; genes located between them are omitted).
• OVERLAPPING_LNCRNAS_gene1_gene2 gene ID is used for ORFs located in a locus overlapping with no protein coding gene but overlapping exactly two non coding genes (gene1 and gene2).
• OVERLAPPING_LNCRNAs_gene1_to_gene2 gene ID is used for ORFs located in a locus overlapping with no protein coding gene but overlapping with at least three non coding genes (the name of the two genes are the one located at extremal positions; genes located between them are omitted).
• INTERGENIC_GENE_chrName gene ID is used for ORFs located in a locus of the chromosome chrName, where there is not any known gene.
• CONFLICT_GENE_gene1_gene2_chrName gene ID is used for ORFs located on the chromosome chrName and on a known transcript but for which conflicting information regarding the gene were provided in the origial data source. This happen when the same data source is associating a particular transcript ID with two distinct gene IDs. This may happen when (i) the two gene IDs are actually refering to the same gene but the cross-reference was unknown by MetamORF, (ii) the two gene IDs are actually distinct genes (in such case the mistake comes from the original data source and MetamORF was not able to solve the issue).

How are registered mitochondrial and sexual chromosomes in MetamORF?

The ORFs (or genes) located on mitochondrial chromosomes are registered as located on the MT chromosome.
The ORFs (or genes) located on a specific sexual chromosome (i.e. either X or Y), are defined using the appropriate chromosome name (X or Y). The ORFs (or genes) indifferently located on the X or Y chromosome are registered as located on the X|Y chromosome.
The chromosome names are saved without the 'chr' prefix in the MetamORF database.

Which genome annotations are you using in your database?

All coordinates are using GRCh38 (hg38, Ensembl release 90) genome annotations for H. sapiens and GRCm38 (mm10, Ensembl release 90) genome annotations for M. musculus.

I am confused about the start and stop (or end) coordinates? Why are stop and end coordinates always higher than the start coordinates, even for ORFs or transcripts located on the reverse strand?

When it comes to provide start and stop (or end) coordinates, to improve programming efficiency, it is easier to consider the start coordinates as the lower bound of the genomic area considered, and the stop (or end) as the higher bound of the genomic area; whatever it actually corresponds to the start or the stop (or end) coordinates.
Hence, this is the strand that will give you information about the actual start and stop (or end) of the ORF, CDS or transcript. For instance, the position of the start codon will be registered in the start attribute for an ORF located on the forward strand whilst the position of its stop codon will be registered in the stop attribute.
On the contrary, the position of the start codon will be registered in the stop attribute for an ORF located on the reverse strand whilst the position of its start codon will be registered in the start attribute.
Be carefull, the coordinates of the ORF exons do not follow this convention. On the contrary, they are provided using their order on the transcript, meaning that the first coordinate will always correspond to the coordinates of the first nucleotide of the first codon of the exon. Be also aware that on ORF pages, the coordinates are registered by exon (the first coordinates corresponds to its start whilst the second corresponds to its end). In the exported CSV files, exon start and ends are registered in two different columns. Please see the documentation related to the ORF page and related to the CSV exports for more information.

To which nucleotides are actually corresponding the start, stop and end positions?

The start position is always providing the coordinates of the first nucleotide of the feature, i.e. either the location of the first nucleotide of the start codon of an ORF, or the location of the first nucleotide of the exon of an ORF, or the location of the first nucleotide of the start codon of an CDS, or the location of the first nucleotide of the transcript.
The stop positions is always providing the coordinates of the last nucleotide of the feature, i.e. either the location of the last nucleotide of the stop codon of an ORF, or the location of the last nucleotide of the exon of an ORF, or the location of the last nucleotide of the stop codon of an CDS, or the location of the last nucleotide of the transcript.
Keep in mind that start and stop (end) position may be reversed for features located on the reverse strand. See the previous question for more information regarding this issue.

I am confused about the absolute coordinates? What coordinate counting system do you use?

MetamORF web interface is displaying both the start and end coordinates of features in a 1-based sytem (fully-close system, also sometimes inaccuratelly called 1-based start, 1-based end system). The coordinates are stored in our database using the same system and coordinates exported in CSV and FASTA files are also using a 1-based coordinate system.
Caution: In order to respect the usual conventions, the coordinates exported in BED file are saved in a 0-based start, half-open (also inaccuratelly called 0-based start, 1-based end) system.
If you are confused about these definitions, we strongly advice to read this article published on the UCSC blog which provides detailed information regarding the coordinate counting systems.

What are the difference between absolute and relative coordinates? Why are the relative coordinates sometimes missing? Which ones should I use?

Absolute coordinates are providing the coordinates on the chromosome, in a 1-based (fully-close) system, meaning that the first nucleotide of the chromosome is numbered 1. Using absolute coordinates allows to locate features anywhere on the chromosome, including in intergenic regions or intron. Nevertheless, because of intron excision during the splicing (and alternative splicing) two features located in distant places on the chromosome can be actually near to each other on the transcript. Hence, relative coordinates provide the location on the features on the transcript. Because we are sometimes missing information about the transcript, it is thus impossible to compute relative coordinates. Moreover as relative coordinates are defined relatively to the transcript, you will always find them related to a particular transcript (and relative coordinates may vary for ORFs that are expressed on different transcripts).
Absolute coordinates are provided by the data sources and lift overed to the last annotation version (i.e. converted from their original annotation to the current one), whilst relative coordinates are computed using the R ensembldb and annotationHub packages. When possible and if you are working on the genome, we advice to use absolute coordinates as they went over less computational steps and misconversion may sometimes happen. Nevertheless, if you are working on transcripts, the relative coordinates are more relevant and should more likely be prefered.

What is the difference between an ORF and a CDS?

Open Reading Frames (ORFs) are usually defined as sequences delimited by a start codon and a stop codon and potentially translatable into functional peptides or proteins.
Coding DNA sequences (CDSs) are usually defined as ORFs actually translated into functional proteins. For more clarity, we considere here the CDSs as the canonical sequences of the transcript actually encoding a functional protein.
Hence, ORFs registered in MetamORF are newly identified ORFs and many ORFs may be located on the same transcript, whilst there is at most one CDS on a transcript. Our algorithm relies on these definition to annotate the ORFs. See the ORF annotation section of this documentation for more information regarding the nomenclature we used to define the ORFs.

What are the nucleotides included in the flanking sequences around the start codon?

When the transcript of an ORF was known and the relative coordinates of the ORF susccessfully computed, we tried to recover the sequences around the start codon of the ORF (by querying Ensembl databases). The nucleotides from the -6 position to the +1 position were included in this sequence, where the +1 position correspond to the first nucleotide of the start codon. Hence, this sequence is always containing exactly 10 nucleotides. The flanking sequences were used to compute the Kozak context.
e.g. If the flanking sequence is 'GCCACCATGG', then the ORF has ATG as start codon (+1 to +3 positions), GCCACC as sequence upstream of the start codon (-6 to -1 positions) and G as sequence downstream of the start codon (+4 position).

According to you MetamORF contain unique entries. Still, when I am looking at data in a genome browser it seems that a lot of ORFs are similar. How is that possible?

Two ORFs are considered as identical if they have:
- The same chromosome name
- The same strand
- The same genomics coordinate for the start position
- The same genomics coordinate for the stop position
- The same number of exons
- The same genomics coordinates for the start and end of each exon
Hence, two ORFs that have at least one of this attribute which varies will be considered as different and registered as two distinct entries (with two different IDs) in MetamORF. It may happen that two ORFs share a lot of common information and only differ on one of these attributes (e.g. same features except for the start codons which are located at two position spaced of 6 nucleotides), in which case they will look very similar on genome browsers, still they are actually different (according to this definition).

I have data about sORFs that might be of interest for your database. How can I submit data to be included in MetamORF?

If you have data describing new sORFs, we would be happy to integrate them in our database. Nevertheless, the processing of data by MetamORF is computationally heavy and integration of new data cannot be fully automatized. So please contact us to discuss about this.
In order to facilitate the integration of new data in MetamORF, please note that:

• Data should specifically be describing short open reading frames (sORFs),
  
• Both computational predictions and experimental data will be considered for inclusion,
• Data describing canonical open reading frames will not be considered for inclusion,
• Data sources already included (see previous section of the documentation), in particular being part of sORFs.org database (and already inserted in MetamORF), will not be considered for inclusion,
• You may find here guidelines regarding the format we expect to facilitate the integration of your data in MetamORF. Fell free to contact us if you have any question.

MetamORF web interface is not working fine. I found information that seems to be inaccurate in your database. I have a question that is not treated in you FAQ.

If you are facing one of this issue, please contact us so we can help you and ensure there is no bugs in MetamORF or fix them. We tried to address about the most frequently asked question to complete the documentation, some of them may be missing, so please contact us when you have a question so we can fill it!

How should I cite MetamORF?