Various comments, mostly administrivia

[cmungall]

Documentation

Your README is great but it launches into in the weeds stuff:

The purpose of the current work is to obtain a namespace for NMRCV under the OBOFoundry.
Robot tool was used to generate an error report and address as many issues as possible.
Some errors such as identical classes with different identifiers can not be fixed without resorting to multiple asserted parent class.

Consider making this a bit more user-centric. Start with what domain nmrc covers, what kind of terms are in it, who should use it and why

It is nice you cite robot but you may want to put this further down

I don't think any user cares about multiple asserted parent classes

Make an obo-format release

We choose the OWL Syntax over the OBO format as exchange syntax for the CV, as the OBO tools are instable, the OBO format is only established in the biology domain (lack of off-the-shelf development tools, OBO expressivity is not as formal as OWL-DL) and there are hence less resources to integrate with

To be pedantic, OWL isn't a syntax. And formally OBO expressivity is as formal as OWL-DL, it is just less expressive. But pedanticism aside, for better or for worse, most bioinformaticians mess up owl, and there are hundreds of obo parsers, you are potentially cutting yourself off from many users.

And in fact you are only using a small fragment of OWL-DL, one that fits within obo easily

It's standard to release a less expressive obo format version alongside the owl (robot/odk will do this for you)

Confusingly, your ontology has a 'curator note' In case we like to be able to convert this owl CV back into the obo format, we should only use DL/owl constructs that are supported by obo. Hence, editors of this CV should take care not to use any higher descriptrion logics semantics, i.e. cardinality restrictions or defined terms using constructors

I think this is out of date. You should use whatever expressivity you need. If some axioms cannot be translated to obo format this is fine, most users do not care about advanced OWL constructs.

There is also obojson which is syntactically easier

do not bring in all of bfo

bfo is a very confusing ontology for 99% of users. I do not recommend bringing in any more than you need to.

you can use robot extract to do this - odk will set you up with a standard workflow for this

I would also consider making a basic release file that excludes bfo altogether, it isn't doing any work for you here

reuse chebi

I believe all of the following should be in CHEBI, I recommend reusing:

'1,4-Dioxane'
'2,2-Dimethyl-2-silapentane-5-sulfonate'
acetonitrile
'sodium acetate'
tetramethylsilane
'Trimethylsilyl propionate'

Consider using odk

This will give you more standard naming conventions, a standard pipeline for validation/QC, module extraction...

add a license declaration to the header

I'm glad you are CC-0

Add a license declaration to the ontology header to be OBO-compliant (see robot report output)

[proccaserra]

@cmungall thx for the review and comments. greatly appreciated. It is true some of the documentation is dated and I will leave @DSchober to comment as I too raised this issue. I made the same case to import chemical entities from CHEBI as the current set up causes (i.e. 2 classes with 2 distinct uri for the same entity). Hopefully, we'll be able to address those issues in the coming releases.