switching to ODK for the maintanance of RXNO & MOP

[StroemPhi]

There are a lot of open issues (e.g.: #37, #30, #28, #27) that could be resolved better with a repository structure and workflow as layed out by the Ontology Development Kit (ODK). Switching to an ODK workflow would not just make the development and maintanance of RXNO & MOP much easier and less error prone, but would also ensure these two to adhere to the OBO Foundry principles, as most of them are checked for in the quality control checks implemented in ODK.

As we already use RXNO in NFDI4Chem and plan on using / contributing more to it, I started working on the ODK migration in our NFDI4Chem fork, documenting it in its wiki. I have talked about migrating a repo to ODK in general with @matentzn in late 2021 and I will follow the inofficial "how to video" he shared with me as the basis.
An important part of this is addressing the fact that MOP and RXNO are hosted and maintained in the same repository. It seems to me, that creating a repo for MOP would be best, but for now I will go for having an ODK folder structure for each (RXNO & MOP) within the existing rxno repo.

The following TODOs are the needed steps I have identified. Constructive feeback to these steps is very welcome :)

TODOs:

• write documentation on how to set up a VM for the plattform independent use of an ODK workflow
• blocked by import MOP directly into RXNO #27
• create editor files for both ontologies in src folder
• migrate RXNO to an ODK workflow
  • seed repo folder structure with templates
  • export lists of terms with ROBOT|export from recent rxno.owl to be used as input for the building of import modules
  • somehow copy existing RXNO terms including all annotations and axioms into new rxno-edit.owl (using ROBOT filter probably)
  • find out if rxno.makefile is needed for the import module build
• migrate MOP to an ODK workflow
  • seed repo folder structure with templates
  • export lists of terms with ROBOT|export from recent rxno.owl to be used as input for the building of import modules
  • somehow copy existing MOP terms including all annotations and axioms into new mop-edit.owl (using ROBOT filter probably)
  • find out if mop.makefile is needed for the import module build
• test the workflow by making a proper release and adjusting the metadata YAML for the purls to resolve

[StroemPhi]

@colinbatchelor as soon as I have something to show, I will ping you to explain and discuss this, ok?

[batchelorc]

Yes, this is very exciting.