Repository navigation
Conversation
… clean removes it
There was a problem hiding this comment.
🟢 Approval recommended
There are no active review issues for the UBERON temporary-path update.
No open issues 🎉
What changed in this PR
Fixes stale UBERON input reuse in the ontology build by downloading to a consistent temporary path, addressing #1699.
Changes:
- Creates
$(TMPDIR)and useswget -Oto overwrite$(TMPDIR)/uberon.obo. - Converts that downloaded file with owltools, keeping the input within the existing
make cleanscope.
| File | Description |
|---|---|
src/envo/Makefile |
Updates the UBERON mirror rule to download and convert a fresh copy under $(TMPDIR). |
Review effort: Balanced
There was a problem hiding this comment.
Looks cleaner. Could you confirm why we're working with the OBO vs the OWL (and perhaps add that as a comment in the makefile)?
@matentzn any insight there ?
I added the makefile comment. Good idea. I don't know why the build read uberon.obo originally. The download-then-owltools step comes from where @cmungall explained that the OWLAPI inside owltools did not follow the PURL redirect and tried to parse the error page. The failing command there already read It also notes that mirroring |
|
Was using OBO instead of OWL a pragmatic solution to avoiding the numerous axioms that are imported into EnvO for Uberon? Who else uses |
|
If we decided to import OWL instead of OBO, would ROBOT has an elegant solution for not importing anything other than subClasssOf assertions? |
It may have been - this is some years back, so recollection is foggy and documentation wasn't so high on the agenda. If we can use the OWL file with ROBOT stripping away superfluous axioms (for import purposes), this would be better in my opinion. |
matentzn
left a comment
There was a problem hiding this comment.
On the questions for me (@pbuttigieg, @turbomam):
Why OBO and not OWL? Historical. My guess is the usual one from back then: uberon.owl was heavy (imports, GCIs, taxon constraints) and the OBO was the lighter thing to grab. It hardly matters for the output, though. --make-subset-by-properties -f $(KEEPRELS), --remove-external-classes and the annotation stripping cut the mirror down to the same small graph from either format.
Can ROBOT strip it down to subClassOf? Yes. filter/remove take --axioms (subclass, equivalent, logical, annotation, external, ...), so something like robot merge -I .../uberon-base.owl remove --base-iri UBERON --axioms external filter --axioms "subclass" --trim false gets you subClassOf only. ODK goes further with extract -m BOT on the seed plus its minimal/"simple" import modes. That's #1703. I agree with @pbuttigieg that it's the better setup, but it doesn't need to block this.
Who else uses tmp/? validate-dl-profile (tmp/validate.ofn) and a few targets in envo.Makefile (tmp/envo-edit-merged.owl, tmp/tags-dosdp.*). They're all scratch files, src/envo/tmp is gitignored, and make clean empties it, so a downloaded OBO fits there fine.
The
mirror/uberon.owlrule ran wget with no-O, souberon.obolanded insrc/envo/. On a second build wget saved the download asuberon.obo.1and owltools converted the old file. The rule now runsmkdir -p $(TMPDIR), downloads with-O $(TMPDIR)/uberon.obo, and owltools reads the file from there. That puts the download undermake clean. The rule keeps its comment linking the PR below.I checked this in
obolibrary/odkfull:v1.6on 2026-11-02. Two forced rebuilds withmake -B mirror/uberon.owlboth exit 0, write onlytmp/uberon.obo, and leave nouberon.obofiles insrc/envo/.make cleanthen emptiestmp/.Related:
Closes #1699