Skip to content

Oort Multiple Ontologies

Shahim Essaid edited this page Feb 2, 2015 · 1 revision

Oort and multiple ontologies

Some of the material on this page is outdated. See also OortExtractingModules

Oort can be used with a single ontology or with multiple ontologies. If you are working with a single ontology, then this page is irrelevant to you.

Startup

Oort allows you to input one or more ontologies. The first ontology is considered the main one, the others are considered reference ontologies. On the command line, the main ontology is always the one entered first. In the GUI, it's also the first ontology in the list.

Bridge Ontologies

The first thing Oort does is look through the list of reference ontologies to determine if any of them are bridge ontologies. A bridge ontology is an ontology that includes only bridging axioms - i.e an axiom that connects classes declared in the main ontology to other classes. A bridge ontology does not include metadata such as labels.

Examples of bridge ontologies can be found on the GO xp page.

The use of bridge ontologies is in part a holdover from obo-format, which did not have good support for ontology importing.

Every bridge ontology found by Oort is merged into the main ontology. Thus if you were to load go.obo as your main file, together with bp_xp_cl and cl.obo, then bp_xp_cl would be merged in to go. This is the desired behavior, as we will see in the next section

Merging in subsets of external ontologies

Oort will generate a file called XX-merged.{obo,owl}. This includes

  • The core ontology (including any bridge ontologies that have been merged in)
  • Any classes that are referenced in the core ontology (or any bridge ontology) that can be found in the referenced ontologies
  • All ancestors of these classes.

See the OBI MIREOT docs

For example, if we load go + bp_xp_cl + cl, then the merged file will include all of GO, all of the axioms in bp_xp_cl that reference a CL class, and the 500 or so of the 2k classes in CL that are referenced in these axioms, up to the root.

Note that when finding the ancestors, axioms such as DisjointWith are not traversed.

In future there will be more customized control over how the closure is constructed, including use of standard OWL modularization technologies. For now if you want anything fancy you have to do the processing yourself upstream.

Imported from tag

Oort includes support for http://purl.obolibrary.org/obo/IAO_0000412 "imported from".

When external classes are merged in to the main ontology, this property is automatically added. In obo-format it ends up looking like:

id: GO:nnnn
name: ...
...
property_value: IAO:0000412 http://purl.obolibrary.org/obo/go.owl

When merging in external classes (see above), as a first step, any classes or relations with this tag are removed.

More Info

See Mooncat API docs (Multiple OWL ONtology Catenation)