For context see: EnvironmentOntology/envo#255
For defining classes such as high-radiation environments we need a core ontology of radiation processes. NPO_1731 ! radiation and it's descendants fit the bill.
So far for ENVO we have not imported any modules from non OBO library ontologies. It makes it easier in terms of our pipeline to stick to OBO lib but we'd rather reuse than reinvent.
- license: looks like you have a BSD license. How does this work with ontologies? How would this affect the CC-BY of ENVO if we import a subhierarchy of NPO? Would we need to license chain?
- Class PURLs: are you committed to bioontology hash purls?
- Object Properties: have you considered importing RO? We may only need the subclass hierarchy but in the case we need more, it would be nice not to have to remap
- Annotation Properties. Ditto, but w.r.t IAO, particularly the definition field.
Alternatively, you could go through the process of OBO-izing NPO, see #4
OR, it seems NPO is a mixture of imported ontologies and native classes, where native classes combine the nanoparticle domain plus other terms where no suitable bioontologies exist, e.g. physics.
Have you considered budding off sub-modules into their own fledgling ontologies? For example, radiation could end up in a general physics processes ontology. This wouldn't be a trivial undertaking - lots of IRI rewriting, a possibly more complex import chain. We'd also have to think about where REX fits in this - it seems like a good ontology but AFAICT has no maintainer.
Note that we are engaged in this kind of budding off with ENVO, seeding new ontologies, cc @pbuttigieg so if you are interested we can share best practice.