GFVO: the Genomic Feature and Variation Ontology

Generic feature and genomic variation file formats

GFF3 is a cornerstone in many GMOD tools, (http://www.gmod.org), such as the generic genome browser GBrowse (Stein et al., 2002), it is input to genomic variant annotation tools such as ANNOVAR, (Wang, Li & Hakonarson, 2010), and it is used to format results of genome annotation pipelines such as MAKER, (Cantarel et al., 2008). The GFF3 specification also includes the FASTA file format specification, since FASTA file contents are permitted in the trailing part of GFF3 files. Genomic variations are represented using either GVF or VCF file formats, which are utilized interchangeably in projects of the European Bioinformatics Institute’s (EBI; Lappalainen et al., 2013), the 1,000 Genomes Project as well as the Broad Institute (The 1000 Genomes Project Consortium, 2012), among other data providers.

GFF3-, GTF-, GVF-, and VCF-specifications define tab-delimited text file formats, which are instances of flat file formats. For all specifications, the text file contents are of variable column-length and additional predefined delimiters (such as a semicolon) are being used for further value separation within certain columns. Multiple Perl-inspired (http://perldoc.perl.org/index-pragmas.html) “pragma” statements are typically declared in the beginning of the files to further determine the interpretation of genomic data contents below. Genomic data are either annotated in predefined columns (tab-delimited; column position determines data content), where some columns are allowed to contain multiple tag/value pairs, or, other composite or ordered data structures (e.g., lists). Figure 1 shows an example of a GFF3 file and the implicit relationships between data within it.

From flat files to a machine interpretable data format

Differences in the genomic feature and variation file formats require multiple software implementations for reading their data files, where data integration across file formats is difficult due to disparities in data labeling and data encoding. The goal of this paper is to overcome these issues by introducing the Genomic Feature and Variation Ontology (GFVO), which addresses this status quo by providing well described named ontological concepts and relations, by defining formal constraints on them, and by potentially enabling unified data access through a generic data representation.

GFVO predominantly unifies naming conventions and data encoding by introducing unique concepts for genomic features and variation representation. For example, the GFVO class “SequenceVariant” expresses sequence variants that are encoded using the “Variant_seq” attribute in GVF files and as either “ALT” column or “ALT” information field in VCF files. GFVO also resolves encoding differences between genomic feature and variation file formats. For example, gametic phase is encoded very differently in GVF and VCF file formats. GVF denotes gametic phase with its “Genotype” attribute in conjunction with “Phased” attribute, or alternatively, “##phased-genotypes” pragma statement. VCF denotes gametic phase in its “GT” additional information field using the special characters “∣” (phased) and “/” (unphased). In GFVO, gametic phase is represented via the unique class “GameticPhase” that encodes both GVF and VCF use cases.

Secondarily, GFVO enables easier data processing and data integration due to the use of World Wide Web Consortium (W3C) backed data standards. Data represented by GFVO can be expressed in one of the many interchangeable Semantic Web file formats (s.a. RDF N-Triples, RDF Turtle, or JSON-LD). Data in those formats can be parsed in many popular programming languages, or, it can be directly loaded into database management systems without requiring further data transformation. For example, RDF Turtle can directly be imported into Virtuoso and other triple stores, while the newer JSON-LD can be imported into MongoDB, Elasticsearch, and other NoSQL database management systems.

Ontology design

GFVO was designed to mirror the class and object property hierarchies of the Semanticscience Integrated Ontology (SIO; Dumontier et al., 2014) release version 1.0.10. SIO is an ontology of basic types and relationships for biomedical knowledge discovery that serves as an upper-level ontology to GFVO. The term upper-level ontology has been defined as a highly abstracted ontology that does not refer to identifiable and/or concrete entities of a domain, but also as an ontology that can be used to impose structure on a lower-level ontology as well as provide relations to other ontologies (Musen, 2013). SIO adheres to the latter by ensuring semantic interoperability via relations between SIO classes as well as properties and the Basic Formal Ontology (BFO; Grenon, Smith & Goldberg, 2004), Relation Ontology (RO; Smith et al., 2005), and the Phenotypic Quality Ontology (PATO) (http://obofoundry.org/wiki/index.php/PATO:Main_Page). Formal relationships between GFVO’s and SIO’s classes and properties are included in GFVO via “owl:equivalentProperty” and “owl:equivalentClass” OWL-properties respectively.

Terminological requirements to describe data contents as covered by the GFF3 version 1.21, GTF version 2, GVF version 1.07, and VCF version 4.1 & 4.2 specifications were gathered by tabulating all named data elements within the specifications. Terminology from specifications was preserved wherever possible, unless a single unifying term seemed more appropriate. This design decision results in pre-coordinated GFVO classes. Pre-coordinated classes are understood as the combination of atomic concepts, e.g., GO accession “GO:0006260” that is labeled as “DNA replication,” (Ashburner et al., 2000), whereas post-coordinated classes are interpreted as the combination of atomic classes via relations and axioms. The widely utilized SNOMED CT uses pre-coordinated terminology too, where post-coordination has been shown to have possible negative effects in terms of misinterpretation of composed SNOMED CT classes (Rector & Iannone, 2012). Pre- and post-coordination have been studied in biomedical sciences in general and it has been found that pre-coordinated ontologies require less user guidance (Schulz et al., 2010). Table 2 provides an overview of the number of GFVO classes that are representing data as it can be found in the genomics feature and variation file formats.

Naming conventions in GFVO are requiring camel case rules for all identifiers, which have to be accompanied by an English-language label for classes and properties (“rdfs:label”). The camel case for class identifiers starts with an upper case letter (e.g., identifier “CodingFrameOffset” with “Coding Frame Offset” as “rdfs:label”). Object- and datatype-properties start with a lower case letter (e.g., identifier “isPartOf” with “is part of” as “rdfs:label”). Identifiers and labels in GFVO were chosen as close as possible to the genomics file format specifications to assist with the adoption of the ontology by bioinformaticians and life science researches.

Similar to SIO, only one datatype property was modeled for representing literal values. Domain- and range-restrictions have been placed as machine interpretable reasoning support that also serve as application guide. Designated object properties have defined range restrictions to the Sequence Ontology (SO; Eilbeck et al., 2005), Variation Ontology (VariO; Vihinen, 2013) and Feature Annotation Location Description Ontology (FALDO; Bolleman et al., 2014, pre-print). The utilization of existing ontologies for specific data representation needs facilitates data integration among genomic data resources through ontology reuse. Examples are provided as Supplemental Information that show the intended use of GFVO including the use of the aforementioned ontologies in conjunction with GFVO.

Descriptive explanations about GFVO’s 102 classes, 33 properties and their intended usage have been provided in comment sections (“rdfs:comment”; cf. tutorial by Horridge et al., 2007). It is shown in Table 3 that the comment sections in GFVO add substantial documentation in comparison to FALDO, SIO, SO, and VariO. Tables 4 and 5 in Supplemental Information break down detailed mappings between the genomics specifications and GFVO, FALDO, SO, and RDF Schema; Table 4 maps every GFVO class to data content in the genomic file formats, whereas Table 5 shows use of FALDO, SO, and RDF Schema. Where applicable, GFVO references Wikipedia (“rdfs:seeAlso”) to provide extra information about the concept that classes encapsulate. References to GFF3, GTF, GVF, and VCF specifications (“rdfs:isDefinedBy”) are denoting the modeling origin as well as applicability of classes to the respective file formats; ¹ the instantiation of classes is not restricted by this annotation though and it is encouraged to make use of GFVO classes according to data representation needs.

Ontology testing

Protégé 4.3 (http://protege.stanford.edu) with HermiT 1.3.7 reasoner plug-in were used to test whether GFVO is free of inconsistencies and unsatisfiable classes—within the reasoning boundaries of HermiT. No inconsistencies were highlighted by the reasoner and inferred class and property hierarchies have been manually evaluated and it has been determined that they follow the intended design.

Examples were created for selected use cases, which also serve as test bed for verifying the ontology’s expressiveness. Examples 1, 2, 3, 3a, 4, and 5 in Supplemental Information show a possible solution for encoding genes and their transcription factor binding sites, sequence alignments, phased and unphased genotypes, sequence variants, and Phred quality scores, and data filtering/annotating, respectively. All examples were inspected for errors using Protege/HermiT; no errors were shown regarding the RDF Turtle format and the example are inconsistency free.