make: *** No rule to make target 'build/subsets/ro-eco.owl', needed by 'subsets/ro-eco.owl'. Stop.

[anitacaron]

When running the RO release, this error occurs when generating the ro-eco subset.

It's defined in the custom Makefile as:

obo-relations/src/ontology/ro.Makefile

Lines 130 to 131 in f06235f

	subsets/ro-eco.owl: build/subsets/ro-eco.owl
	$(OWLTOOLS) --use-catalog $< --remove-dangling -o $@

However, I don't see build/subset folder anywhere in the repository. It might get lost when moving to ODK or be a hidden folder. This subset has not been updated since 2 years ago.

If we comment out this rule in the custom makefile, then it will fall under the default subset workflow as:

obo-relations/src/ontology/Makefile

Lines 617 to 620 in f06235f

	$(SUBSETDIR)/%.owl: $(ONT).owl | $(SUBSETDIR)
	$(OWLTOOLS) $< --extract-ontology-subset --fill-gaps --subset $* -o $@.tmp.owl && mv $@.tmp.owl $@ &&\
	$(ROBOT) annotate --input $@ --ontology-iri $(ONTBASE)/$@ $(ANNOTATE_ONTOLOGY_VERSION) -o $@.tmp.owl && mv $@.tmp.owl $@
	.PRECIOUS: $(SUBSETDIR)/%.owl

Any ideas? @balhoff @cmungall @jamesaoverton @matentzn

[gouttegd]

My understanding is that, prior to the ODK transition, the build/subsets/ro-eco.owl file was automatically generated by OWLTools’s “Ontology Release Runner“ (OORT). Now that we are no longer using OORT, that file is no longer generated and the rule in the custom Makefile has nothing to work with.

A quick workaround that does not even involve modifying the custom Makefile is to manually invoke the build-with-oort prior to running a release, e.g. with

sh run.sh make build-with-oort prepare_release

This would explicitly call the Ontology Release Runner and create the required build directory with all the OORT-generated files (including the build/subsets/ro-eco.owl file.

However it is kind of ridiculous to run an entire OORT-driven release solely for the purpose of creating the build/subsets/ro-eco.owl file. A better solution would be to avoid depending on OORT at all.

OORT creates the subset files (for any subset defined within the ontology) by basically

1. getting the list of classes in the subset (mooncat.getGraph().getOWLClassesInSubset(subset));
2. creating a “minimal subset ontology” out of it (mooncat.makeMinimalSubsetOntology(objs, iri)).

This is exactly the same logic used by OWLTools’ --extract-ontology-subset command when the --fill-gaps option is not used.

So it should be fine to replace the existing rule in the custom Makefile by something like:

$(SUBSETDIR)/ro-eco.owl: $(ONT).owl | $(SUBSETDIR)
        $(OWLTOOLS) $< --extract-ontology-subset ro-eco --remove-dangling -o -$@

[balhoff]

I recently removed OORT from the GO pipeline and implemented subsets using ROBOT this way: https://github.com/geneontology/go-ontology/pull/29705/files

(I am also removing owltools so didn't want to introduce the command that @gouttegd showed)

[gouttegd]

However

It is worth noting that, regardless of how the ro-eco.owl subset is generated (with OORT or with --extract-ontology-subset), it is probably not what you would expect!

OWLTools’ code to create subsets (used by both OORT and --extract-ontology-subset) is intended to work with classes only. It is not designed to extract a subset of properties.

[matentzn]

Ask @cmungall if he remembers the purpose of that subset on slack.. maybe its as easy as replacing it with robot or odk subset (once it exists)

[gouttegd]

odk subset (once it exists)

The odk:subset command is designed to work in the same way as OWLTools’ subset creation commands (--extract-ontology-subset, --make-ontology-from-results), so it is also designed to work with classes only. Used here, it would produce the same bogus subset as what is currently produced with OORT.

If nobody ever noticed the subset was bogus, is it really needed at all?

[matentzn]

Some history stuff:

https://github.com/EnvironmentOntology/envo/blob/14e5dc567ffa76f24a5d0fe396e88a8acc66861f/src/envo/releases/2015-12-18/subsets/ro-eco-metadata.txt#L4

Quick guess:

1. @cmungall created ro-eco as a subset for RO in 2015 (for use in ENVO).
2. It was used for a bit but then later replaced by "ro base file and robot imports"
3. ro-eco is no longer needed - or sorely needed, and we need to build a system that can create (semantic preserving) ro subsets more easily

[anitacaron]

I am waiting for @cmungall's confirmation that we don't need this subset anymore.

[cmungall]

not needed