Inter-ontology Links
From OBO Foundry
One of the principle goals of the OBO Foundry is to create an interconnected collection of orthogonal ontologies covering all domains of biology and biomedicine.
If we conceive of an ontology in terms of graph theory, then all ontologies have intra -ontology links such as "nucleus part_of cell". These are made using relations from RO. In addition, it will be necessary to have inter-ontology links. For lack of a better word we call these mappings.
From a logical point of view, the distinction between intra-ontology and inter-ontology links is not crucial; it should be possible to consider the entire OBO Foundry as a single coherent ontology. However, from the point of view of managing and coordinating ontologies it is useful to draw a distinction. For example, separate groups may be responsible for maintaining inter-ontology links than those maintaining intra-ontology links.
Here we outline the different kinds of inter-ontology links that are important to the OBO Foundry. This page also includes discussion of inter-ontology logical definitions. Technically speaking these are not mappings, as they are not 1-to-1 correspondences. Rather, each logical definition is for one class in terms of two or more classes (which may come from separate ontologies).
Note: for readability we use IDs such as CL:cell rather than the actual ID, which would be CL:0000000 (or http://purl.org/obo/owl/CL#CL_0000000)
Contents |
Availability
Mappings which conform to the principles below will be available as part of the OBO Foundry on the mappings page
Equivalence Mappings
In OBO Foundry terms, an equivalence mapping is a pairwise mapping between two terms/classes that represent exactly the same type in reality.
The OBO Foundry is a collection of orthogonal ontologies. It then follows there should be few equivalence mappings, since ontology editors should strive to avoid redundancies. However, it is expected that there may be some redundancy at ontology join points. The paradigmatic example here is between GO:cell a CL:cell. Both terms represent the same type in reality, but it is useful to have redundant terms in both ontologies: GO-CC is a mereological representation of cells, CL is a representation of types of cell and the developmental relations between them.
Where there are cases of such redundancy, it is recommended that both ontologies use identical textual definitions
Examples
- GO:cell = CL:cell = CARO:cell
These 3 ontologies each have a term that represents the same type. It is natural that something fundamental like a cell be the "join point" between ontologies
Counter-Examples
- CL:cell != ZFA:cell
These terms do not represent the same type; ZFA:Cell is more specific. See #is_a_mappings.
- ZFA:heart != FMA:Heart
This would be a homology link (see below)
- AvianAO:wing != MammalianAO:wing
This is neither an equivalence link nor a homology link (bat wings and chicken wings are not homologous as wings -- though they are homologous as forelimbs). We would probably not link these directly; they could be indirectly linked via a link to a common function.
- GO:cell != MESH:Cell
Note: under discussion
Any link to terms/classes outside the OBO Foundry should follow the non-Foundry links recommendations, below. This is particularly important for non-ontology artefacts such as MESH -- even in cases such as the above, when we can be reasonably sure the two resources are referring to the same kind of thing. This is not to diminish the importance of ex-foundry resources, it is simply important to treat these differently for the purposes of logical reasoning.
Note that applications can still treat these classes as equivalence axioms for the purposes of local reasoning
Representation formalism
Equivalence is a pairwise relation between terms (note that in contrast to the relations in OBO_REL, this is not a relation between types, as there is only a single type here).
In OWL, this is represented using an owl:equivalentClass axiom.
In OBO, this is represented as an xref tag, with additional metadata in the header
In header:
treat-xrefs-as-equivalent: GO
In the body:
[Term] id: CARO:0000013 name: cell def: "Anatomical structure that has as its parts a maximally connected cell compartment surrounded by a plasma membrane." [CARO:MAH] is_a: CARO:0000003 ! anatomical structure xref: GO:0005623
Note that OBO_REL xrefs are all treated as equivalent. See GO.obo for an example.
[Typedef] id: part_of name: part_of xref: OBO_REL:part_of is_transitive: true
Deployment
It is recommended that equivalence mappings are deployed with the ontology in question, rather than as a separate mapping file. It is also recommended that equivalence mappings are reciprocated.
Technical requirements
It should be possible to automatically collapse equivalent terms for the purposes of logical reasoning. It may still be necessary to treat the terms as distinct (for example, different ontologies may wish to attach different notes-to-annotators on each term).
Both the OBO and OWL solutions fulfil these requirements
Links to records or terms outside the OBO Foundry
Often it will be necessary to link to ontologies, terminologies and ontology-like resources. If these resources do not conform to Foundry practices it is difficult to establish an exact semantics for these mappings. Nevertheless, it can still be important for applications to use these kinds of mappings.
Here we only consider links between a Foundry ontology (A) and some external resource (B)
Examples (GO)
GO has perhaps the richest set of mappings for any .obo ontology
See http://www.geneontology.org/GO.indices.shtml for a list of mappings from GO (a Foundry ontology) to non-foundry ontology-like-resources
EC2GO
EC (Enzyme Commission) numbers are mapped to GO by GO curators; an example is:
- EC:1.1.1.117 ~= GO:D-arabinose 1-dehydrogenase [NAD(P)+] activity (GO:0045290)
The assumption is that the xref denotes equivalence or near equivalence
The EC2GO mappings (and others) are also available as .obo and owl:
Whilst the EC2GO mappings can be considered a separate resource from GO, they are actively maintained by GO curators and are distributed as part of the .obo file
Interpro2GO
- GO to interpro mappings
http://obofoundry.org/cgi-bin/detail.cgi?id=metacyc2go
Contrasting with EC numbers, the relation is not one of equivalence. Protein domains are not equivalent to functions, processes or subcellular components. Rather, there is an implicit relation between a domain and a process or component. This will likely be formalized as part of the Protein ontology PRO.
Examples (non-GO)
- The disease ontology (DO) is distributed with xrefs to UMLS, ICD9
- ENVO is distributed with xrefs to the Getty
Formalism
In OWL, these should be done using an rdfs:seeAlso link
In OBO, these should be done using an xref tag, with the IDspace from a registered resource (see below)
Note that we are currently conflating "analogy" links (eg EC2GO) with other kinds of links (eg a GO function and an interpro domain that confers that function).
Deployment
These can be deployed as either separate mapping files or along with the Foundry ontology. GO, for example, does both.
Technical Requirements
As these links lack coherent semantics these links should be ignored from a logical point of view. However, the links can be extremely important to end users. Thus they should be queryable along with other metadata. Browsers may wish to implement hyperlinks to html pages for external resources using:
It is recommended that an ontology producing mappings to non-foundry resources makes sure the resource is registered here. Email obo-admin AT obofoundry DOT org to have this added.
homology and other cross-species mappings
This is a difficult area - the Foundry will work with evolutionary biologists and anatomists to come up with rigorous mappings here.
The focus will be on homology mappings rather than mappings based on structural or functional analogy. Thus all mappings will require evolutionary evidence.
Examples
- human heart and mouse heart
- human arm and bat wing as forelimb
Counter-examples
- bat wing not homologous_to chicken wing as wing
Representation formalism
The representation formalism is under development. It is likely the relation here should be ternary rather than binary (eg "X homologous_to Y as type Z").
Homology links are examples of links that should be attributable: often homology links are hypothetical, and should thus be linked to provenance information and evidence (in this sense they are very similar to the OBO Foundry formalism for annotations)
Technical Requirements
These may be quite involved. To be written.
At the least, traversal across ontologies should be possible.
Deployment
These should in general be deployed as separate documents/resources. Exceptions are made from multi-taxon anatomical ontologies specifically engineered to represent phylogenetic relations.
is_a mappings
Sometimes it will be necessary for one ontology to include terms that refine terms from another ontology.
- The is_a roots from one Foundry ontology may be linked via is_a to upper ontology classes
- A species-centric ontology may refine a term or defined a species-specific term from a general anatomy ontology
It is recommended that when refining via is_a that discriminating characteristics are also provided. In these cases, the mapping becomes a logical definition (aka cross-product). See below. Often it may be hard to provide discriminating characteristics, in which case, a simple is_a link is fine.
Examples
- ZFA:cell is_a CL:cell
- ZFA:heart is_a CARO:cavitated_compound_organ
- CARO:cavitated_compound_organ is_a bfo:Object
- MP:binucleate is_a PATO:binucleate
the MP terms is specific to mammalia, but the PATO term is for any species
See CARO to BFO is_a links for a concrete example
Partial examples
- TO:carbon_sensitivity is_a PATO:sensitivity
Although correct, this is better done as a logical definition: see below
Counter-Examples
- MA:heart not is_a FMA:Heart
a mouse heart is not a kind of human heart.
Formalism
In OWL, use SubClassOf axioms
In OBO, use is_a links
Deployment
It is recommended that these kinds of cross-ontology mappings are deployed as a separate mapping file. This allows someone to use the more specific ontology in a self-contained manner.
For example, if ontology X extends BFO, the maintainer of X would make available two files:
- X.obo
- X_to_bfo_bridge.obo
The second file is called a bridging file. The second file contains is_a links only
An alternative for OBO files is to link to the parent term using a weak xref link, and include metadata in the header that indicates that xrefs for a particular ID-space should be treated differently; (yet to be fully specified); see ZFA example for now
Technical Requirements
there should be a means of retrieving ontologies A and B distinctly, or as a combined unit with the is_a links.
Reasoning across these links should be standard for is_a relations
part_of and has_part mappings, and other OBO Relations
Sometimes it is necessary for one ontology (A) to provide terms that are more granular than terms in another ontology (B). For example, subcellular components may be represented in one ontology (A=GO) whilst cells or gross anatomical entities may be represented in another (B=CL or B=CARO)
Examples
- CL:nucleate_erythrocyte has_part GO:nucleus
Note: this is better done with a logical definition, see below
- ZFA:erythrocyte has_part GO:nucleus
All zebrafish erythrocytes have a nucleus (we could also use the ZFA-specific nucleus term here, but *not* the CL erythrocyte term)
- ZFA:Purkinje_cell part_of ZFA:Cerebellum
All ZF purkinje cells are part of a ZF cerebellum
Counter-Examples
- CL:purkinje_cell part_of ZFA:cerebellum
This says that all purkinje cells, whatever the species, is part of some zebrafish cerebellum. See: http://www.bioontology.org/wiki/index.php/CL:Aligning_species-specific_anatomy_ontologies_with_CL
The recommended practice here is to create a taxon-specific subtype of the CL term and make the link using this (in which case it will be an intra-ontology mapping, or conventional link)
Formalism
These kinds of links constitute the normal sort of links found in ontologies such as GO, the only difference being they span ontologies. They indicate necessary conditions for the term that owns the link.
In OBO, use a relationship tag with an OBO Relation
In OWL, use a restriction, typically existential, with an OBO Relation
Deployment
As for is_a
Technical Requirements
The OBO Relations ontology semantics should be followed
logical definitions
Also known as "cross-products"
For full discussion see:
http://www.bioontology.org/wiki/index.php/XP:Main_Page
Examples
- TO:carbon_sensitivity is_a PATO:sensitivity that towards CHEBI:carbon
For similar examples, see: http://obofoundry.org/cgi-bin/detail.cgi?plant_trait_xp
- MP:tail_length is_a PATO:length that inheres_in MA:tail
For similar examples, see: http://obofoundry.org/cgi-bin/detail.cgi?mammalian_phenotype_xp
- CL:nucleate_erythrocyte is_a CL:erythrocyte that has_part GO:nucleus
See the discussion on part_of links, above
- GO:maltose_metabolism is_a GO:metabolic_process that has_participant CHEBI:maltose
http://obofoundry.org/cgi-bin/detail.cgi?go_xp_chebi
Counter-Examples
- GO:maltose_biosynthesis is_a GO:metabolic_process that has_participant CHEBI:maltose
The conditions are too weak to be considered sufficient for maltose biosynthesis, as this would also include maltose catabolism etc. Use a more specific relation
Formalism
We provide cross products for terms in ontology A using ontologies B, C, D, ... and the OBO Relation ontology. terms from A can also be used in the logical definition.
logical definitions are different from normal inter or intra ontology graph links in that logical definitions provide necessary and sufficient conditions.
In OBO, a logical definition of the form "An X is_a G that D", where the differentium D is a relation R to some term T, is represented as
[Term] id: X intersection_of: G intersection_of: R To
In OWL, it is represented as
X equivalentClass intersectionOf(G restriction(R To))
Deployment
These will be deployed as distinct files to begin with. This makes it easier to
Examples of deployment:
http://www.berkeleybop.org/ontologies/#logical_definitions
It is recommended that ontology A is always deployed for general purpose use with all intra-ontology links that can be inferred pre-instantiated.
The policy on whether to use obo/owl import statements is not yet decided. It may be better to autogenerate an "importer" file from the ontology metadata. For example, the metadata for the GO-ChEBI xps is sufficient to automatically generate this file:
http://purl.org/obo/obo-all/go_xp_chebi/go_xp_chebi.imports.obo
Which is simply a list of import statements to fetch the relevant ontologies from the purl.org URL. At the same time, this imports file can be ignored, and each of the ontologies can be deployed separately.
Technical Requirements
A basic reasoner will be useful for inferring links from logical definitions. This will be particularly useful for annotations that may have post-composed terms using the same formalism.
Foundry Recommendations for pre- vs post- composition
The OBO Foundry has guidelines for when composite terms should be pre-composed and deployed in an ontology, and when they should be combined at annotation-time. These will be posted shortly.
