You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Other tags in that frame removed for clarity, they don’t matter here. What matter are the two disjoint_from tags.)
At some point in the standard pipeline, the -edit file is processed to generate what we call $(SRCMERGED). Basically, imports statement are removed and components and pattern-derived axioms are merged. Importantly, $(SRCMERGED) is in the same format as the edit file, so if the ontology is maintained in the OBO format (as is the case for Uberon), then $(SRCMERGED) is also written in the OBO format. $(SRCMERGED) is then used as input to robot report to generate the reports/uberon-edit.obo-obo-report.tsv report, which is the step that failed in the above PR.
The problem is that, when writing $(SRCMERGED), the disjointness axioms that, in the -edit file, are part of the UBERON:0000001 frame, are now written as if they were part of the frames of the referenced GO terms. That is, the fragment above becomes:
[Term]
id: GO:0005623
disjoint_from: UBERON:0000001 ! gross anatomical part
[Term]
id: GO:0110165
disjoint_from: UBERON:0000001 ! gross anatomical part
[Term]
id: UBERON:0000001
name: gross anatomical part
(I have not looked at the logic used by the OWLAPI to decide in which frame a disjoint_from tag should go, but I suspect the decision is made by lexicographically sorting the IRIs involved in the axiom, and putting the tag in the frame corresponding to the first IRI. In this example, GO:0005623 would be sorted before UBERON:0000001, so the OWLAPI creates a frame for GO:0005623 instead of writing the disjoint_from tag in the frame for UBERON:0000001.)
Now, logically, this does not change anything. A DisjointWith: B is obviously the same as B DisjointWith: A. But the second form makes the missing_label test (part of the standard ROBOT report check) fail, because the GO:0005623 and GO:0110165 frames don’t have a label!
The text was updated successfully, but these errors were encountered:
The easiest fix, I believe, would be to always write the $(SRCMERGED) file in OFN format (or any non-OBO format, really), independently of the format of the edit file.
Make sure the $(SRCMERGED) intermediate file is always written in OFN
format, rather than in the same format than the -edit file.
If $(SRCMERGED) is written in OBO format, this can cause some checks
made on that file to fail because of some peculiarities of the OBO
serialisation that do not accurately reflect the contents of the
original -edit file.
closes#1107
This problem was encountered by Uberon on this PR; see the CI failure report here.
The main change in that PR is the addition of a new term that is disjoint from two imported GO terms:
(Other tags in that frame removed for clarity, they don’t matter here. What matter are the two
disjoint_from
tags.)At some point in the standard pipeline, the
-edit
file is processed to generate what we call$(SRCMERGED)
. Basically,imports
statement are removed and components and pattern-derived axioms are merged. Importantly,$(SRCMERGED)
is in the same format as the edit file, so if the ontology is maintained in the OBO format (as is the case for Uberon), then$(SRCMERGED)
is also written in the OBO format.$(SRCMERGED)
is then used as input torobot report
to generate thereports/uberon-edit.obo-obo-report.tsv
report, which is the step that failed in the above PR.The problem is that, when writing
$(SRCMERGED)
, the disjointness axioms that, in the -edit file, are part of theUBERON:0000001
frame, are now written as if they were part of the frames of the referenced GO terms. That is, the fragment above becomes:(I have not looked at the logic used by the OWLAPI to decide in which frame a
disjoint_from
tag should go, but I suspect the decision is made by lexicographically sorting the IRIs involved in the axiom, and putting the tag in the frame corresponding to the first IRI. In this example,GO:0005623
would be sorted beforeUBERON:0000001
, so the OWLAPI creates a frame forGO:0005623
instead of writing thedisjoint_from
tag in the frame forUBERON:0000001
.)Now, logically, this does not change anything. A DisjointWith: B is obviously the same as B DisjointWith: A. But the second form makes the
missing_label
test (part of the standard ROBOT report check) fail, because theGO:0005623
andGO:0110165
frames don’t have a label!The text was updated successfully, but these errors were encountered: