Open h-spinde opened 1 year ago
I agree that the current structure is confusing. The file readme.md contains this diagram after our large restructuring in issue #1592 for release 2.0.0:
This is much cleaner and should work, too. I don't see a reason why a module is imported multiple times.
Also imho oeo-physical-axioms
should be imported directly to oeo-physical
as it extends that module, but is irrelevant for the other modules.
This is much cleaner and should work, too. I don't see a reason why a module is imported multiple times. Also imho oeo-physical-axioms should be imported directly to oeo-physical as it extends that module, but is irrelevant for the other modules.
@l-emele unfortunately, the figure in README / wiki is currently not the actual state, but the one prepared by @h-spinde.
I started testing an untangling process (see figure below) by importing oeo-import-edits into oeo-shared directly and by deleting omo-extracted (since redundant, based on #1755) in #1754.
@l-emele @h-spinde @nelekoehler @areleu could someone please check the current PR for inconsistencies?
@l-emele unfortunately, the figure in README / wiki is currently not the actual state, but the one prepared by @h-spinde.
Ys, I know. But it depicts very well how the import structure should be. That is why I referenced it.
@l-emele @h-spinde @nelekoehler @areleu could someone please check the current PR for inconsistencies?
I checked: In the PR branch OMO-defined annotations do not exist anymore. But we did not use them anyway.
As you are updating the import structure, this seems also the right time to harmonise prefixes across ontology files, see issue #1651.
I now also removed the redundant BFO import.
Partially solved by #1754 I move it to the next milestone for the remaining parts.
@areleu can we implement a test for imports that checks whether a certain class was already imported before (by another ontolotgy import), to avoid duplicate imports?
Description of the issue
Currently, which file in the OEO imports which is a little confusing, with some files even being imported into multiple different other ones. The structure currently looks like this: oeo-import-structure.pdf
Ideas of solution
There should be some agreement over where each file should be imported into the OEO, so that the structure can be more intuitively understood and redundant imports can be avoided. Ideally, the diagram in the wiki under Modules of the OEO should also reflect the import structure.
Workflow checklist