Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OEO Import Structures #1756

Open
2 of 3 tasks
h-spinde opened this issue Nov 20, 2023 · 8 comments
Open
2 of 3 tasks

OEO Import Structures #1756

h-spinde opened this issue Nov 20, 2023 · 8 comments
Assignees
Labels
[B] restructure Restructuring existing parts of the ontology

Comments

@h-spinde
Copy link
Contributor

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

  • I discussed the issue with someone else than me before working on a solution
  • I already read the latest version of the workflow for this repository
  • The goal of this ontology is clear to me
@h-spinde h-spinde added [B] restructure Restructuring existing parts of the ontology To do Issues that haven't got discussed yet labels Nov 20, 2023
@h-spinde h-spinde changed the title "The issue is <your issue title>" OEO Import Structures OEO Import Structures Nov 20, 2023
@l-emele
Copy link
Contributor

l-emele commented Nov 20, 2023

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:

Structure of the OEO

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.

@stap-m stap-m mentioned this issue Nov 21, 2023
8 tasks
@stap-m
Copy link
Contributor

stap-m commented Nov 21, 2023

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?

grafik

@l-emele
Copy link
Contributor

l-emele commented Nov 21, 2023

@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.

@github-actions github-actions bot removed the To do Issues that haven't got discussed yet label Nov 21, 2023
@l-emele
Copy link
Contributor

l-emele commented Nov 21, 2023

@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.

@l-emele l-emele added this to the oeo-release-2.1.0 milestone Nov 21, 2023
@l-emele
Copy link
Contributor

l-emele commented Nov 21, 2023

As you are updating the import structure, this seems also the right time to harmonise prefixes across ontology files, see issue #1651.

@stap-m
Copy link
Contributor

stap-m commented Nov 23, 2023

I now also removed the redundant BFO import.

@stap-m
Copy link
Contributor

stap-m commented Dec 1, 2023

Partially solved by #1754
I move it to the next milestone for the remaining parts.

@stap-m
Copy link
Contributor

stap-m commented Apr 24, 2024

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[B] restructure Restructuring existing parts of the ontology
Projects
Status: In discussion
Development

No branches or pull requests

4 participants