Testing mapping sets for possible breaking changes

[gouttegd]

Note: The feature requested here may not actually belong to the ODK. Other projects, for example projects related to SSSOM, may be better suited to provide the feature. But we need to describe the feature before we can even decide where it should be implemented.

We need a way to easily check whether changes to a SSSOM mapping set can break things when two or more ontologies are merged together (with the SSSOM mapping sets providing the bridging axioms between the ontologies).

Let’s say the FBbt editor makes a change to the mappings between FBbt and CL. Because FBbt has a lot of non-disjointness axioms to help ensure its internal consistency (whereas CL and Uberon do not), any such change could potentially create problems downstream when FBbt and CL are merged (for example in Ubergraph).

Currently, testing the impact of such a change requires going through complicated hoops:

• in FBbt:
  • make a mock release
• in CL:
  • manually import the FBbt-provided SSSOM file (overriding the default behaviour of CL’s Makefile, which attempts to always download the SSSOM file from FBbt’s GitHub repository – here, we want to test before committing anything to FBbt’s repo, so before anything is available on GitHub)
  • re-generate the mappings.owl component
  • make a mock release
• In Uberon (Uberon is involved even for FBbt-to-CL mappings, because the bridge generation logic is in Uberon):
  • as for CL, manually import the FBbt-provided SSSOM file
  • manually import the mock CL release (again overriding the default behaviour of Uberon’s Makefile, which attempts to get CL from its GitHub repository)
  • make a mock Uberon release
  • generate the bridges
• Elsewhere, in a ad-hoc test directory:
  • Merge the mock releases of FBbt, CL, and Uberon, along with the uberon-to-fbbt-bridge and cl-to-fbbt-bridge
  • Check the resulting merged ontology for inconsistency and unsatisfiable classes.

This is ugly, needlessly complicated, error-prone, and only means that such a check will not be performed as often as it should be. As a result, mapping-generated inconsistencies will most often only be detected when someone does try to merge the involved ontologies (e.g. Ubergraph), which may very well happen months after the faulty mapping change was introduced.

We need a simple method to say, “take these two (or more) ontologies, take these mapping sets between these ontologies, merge everything together (generating the bridging axioms from the mapping sets as needed), and tell me whether the result is consistent.”

[gouttegd]

We need a simple method to say, “take these two (or more) ontologies, take these mapping sets between these ontologies, merge everything together (generating the bridging axioms from the mapping sets as needed), and tell me whether the result is consistent.”

FYI, this is how I am currently doing that to check the mappings between FBbt, Uberon, and CL (relying on a custom-built ROBOT with plugins support and my SSSOM plugin):

merged.owl: fbbt.owl uberon.owl cl.owl fbbt-mappings.sssom.tsv bridging.rules
        robot merge -i fbbt.owl -i uberon.owl -i cl.owl \
              sssom:sssom-inject --sssom fbbt-mappings.sssom.tsv \
                                 --ruleset bridging.rules \
              annotate --ontology-iri http://purl.obolibrary.org/obo/fbbt/uberon-cl-merge.owl \
                       --output merged.owl \
              reason --reasoner ELK | grep unsat | wc -l

The rule:

1. merges all three ontologies together;
2. generates the bridging axioms from the mappings and merges them with the rest;
3. writes out the output to disk (for later manual checking, if needed);
4. tries to reason over the entire merged ontology and reports any unsats.

Here is the bridging.rules ruleset that dictates how to generate the bridging axioms:

prefix FBbt:      <http://purl.obolibrary.org/obo/FBbt_>
prefix UBERON:    <http://purl.obolibrary.org/obo/UBERON_>
prefix CL:        <http://purl.obolibrary.org/obo/CL_>
prefix BFO:       <http://purl.obolibrary.org/obo/BFO_>
prefix IAO:       <http://purl.obolibrary.org/obo/IAO_>
prefix NCBITaxon: <http://purl.obolibrary.org/obo/NCBITaxon_>

subject==FBbt:* predicate==semapv:crossSpeciesExactMatch (object==UBERON:* || object==CL:*) -> {
    create_axiom("%subject_id EquivalentTo: %object_id and (BFO:0000050 some NCBITaxon:7227)");
    annotate_subject(IAO:0000589, "%subject_label (Drosophila)");
}

This could be generalised into a ODK-supported thing: an ontology could declare which foreign ontologies they want their mappings to be checked against, and provide a ruleset file; from there the ODK could take care of the rest.