matentzn
commented
5 years ago After a discussion with David, I propose the following:
- In the config file, we allow to specify "namespaces of interest", which, by default, is the ontologies default entity purl: http://purl.obolibrary.org/obo/FOO_
- We define four new release artefacts (other than base):
- foo-non-classified: (edit->imports-merged)
- foo-simple: (edit->reason,relax,reduce,drop imports, drop every axiom which contains an entity outside the "namespaces of interest")
- foo-simple-non-classified (edit->relax,reduce,drop imports, drop every axiom which contains an entity outside the "namespaces of interest") <- aka the HPO use case, no reason.
- foo-full (whatever we have now in the ODK for foo.owl)
- foo-basic: A version of -simple containing only relationships using relations on a configurable whitelist (default = BFO:0000050 (?)). See above (David comment) for explanation.
- In the config, we allow people to chose which of the four should be their default (which would then be moved to hp.owl, hp.obo). By default the default is full (as it is now).
It is fine IMHO to drop the special case of "retain import statements" -> We just purge that possibility from existence (i.e. we just always merge imports in).
@dosumis can you check I captured the definition of "simple" correctly?
@cmungall To save you some ink: I agree with you that I would rather have a reliable behaviour of hp.owl and hp.obo, them always being the full case. But we need to weigh our desires against the expectation of some important users such as Flybase or the HP user community. We know we (as technically versed people) can chose now freely; and in fact, we will more often than not chose foo-base than foo.owl in any case. So perhaps its a show of love to let the community keep their desired primary artefacts.
dosumis
balhoff
There has been a gradual change in release file content that, unless I’ve not been paying attention (entirely possible), has happened without proper discussion - and certainly without announcement. I particularly want to avoid causing problems for downstream who have embedded assumptions and expectations.
When did we agree that fu.obo/owl should merge in all imports? The OWL files at least used to reference imports. Not sure if OBO files included them - but the it’s clear from the diffs on the ODK update to CL the cl.obo that it did not. The new one seems to pull in most of BFO.
Back when we made releases with OORT, we had a number of ontology file versions that served important use cases (mostly for the OBO world). These have been dropped with the move to Robot.
fu.obo.owl: Pre-reasoned version of editor’s file.
fu-simple.obo/owl - pre-reasoned; Equivalent class axioms relaxed to subClassOf axioms; all axioms referencing terms from external ontologies stripped. The obo version in particular is useful to resources who want a simple graph representation of ‘fu’ terms only. This covers the majority of historic users.
fu-relaxed.obo/owl; As fu-simple but retaining reference to external terms & imports. I may have been the only user of this.
fu-non-classified.obo/owl -> release version of editor’s file. No pre-reasoning.
Many ontologies also produced a fu-basic.obo version. This was like fu-simple.obo, but guaranteed to be a DAG with no double-labelled edges - as all OBO files once were. This was typically achieved by using an OWLTOOLS filter to remove particular relationship types - typically removing the less useful partner of a reciprocal pair - e.g. removing has_part because this is not used in graph-based grouping whereas its reciprocal, part_of, is.
I think we should at least be producing -simple and -basic versions for everything and documenting the content and usage of all release files on the main GitHub readme. It might be worth having the -basic be a version be designed for naive graph-based grouping without any need to pay attention to edge type. This could be configured for each ontology by asking for a list of grouping relations - making clear that this should exclude any reciprocal pairs that potentially lead to cycles. Maintaining DAGness potentially requires ongoing work and so these should be the subject of CI tests.
I think some quick solutions to this are urgent given the current fast and otherwise welcome progress in implementing ODK across the community.
CC @cmungall @balhoff @matentzn