Update process for creation of import modules

[markus-rothkoetter]

Description of the issue

Modul creation used to import terms from existing ontologies (ro-module, iao-module) has currently some problems are: (Detailed descriptions of some of these issues might be read in the linked issues which are meant as reference only)

• [ ] ro-module will loose the manual changes upon recreation #1118
• [ ] ro-module contains some improper entries belong to different ontology parts
  (list in the comments of #1118)
• [ ] iao-module was created in a fully manual process #1132
• [ ] term tracker items can mess up the auto-generation #1119
• [ ] term tracker items are partly saved in oeo.omn
• [ ] term tracker items are partly in imported modules #1132

Key questions to solve

• Where to store the term tracker item ...
  • ... added to the class itself ➔ can be separated from class on file-level basis (via "Pull into/Move to ontology" in Protégé)
  • ... added to the affected axioms ➔ can NOT be separated from axiom on file-level basis
• Where are custom axioms e.g. domain + range stored?
• How do we carry definition updates/restructurings in source ontology over to the OEO?
• How do we prevent overwritten edits on autogenerated files?
• How do we prevent the usage of relations which were meant as "grouping-only" by the creators of external ontologies?

Ideas for solution

In the following an idea for an improved architecture is shown. It is based on separating all edits (term-tracker + axioms) concerning imported terms into a file customization.owl (This could also be the oeo-shared, but in terms of separation of concerns a dedicated file is better in my opinion.)

import-module is a placeholder for either ro-module or iao-module or ... This means there has to be a terms list for each module.

(If the flowchart is to small, click on the enlarge button in the top-right corner.)

graph LR;

subgraph "created for each <br> import-module"
TL1["📄 <br> terms-without-hierarchy.txt"]
TL2["📄 <br> terms-without-hierarchy.txt"]
end




Robot["🤖 <br> ROBOT-script"]

  
TL1-->Robot;
TL2-->Robot;

Robot -- composes --> RO

CI["🐙 <br> GitHub CI-Test"]
CI -- enforces read-only --> RO

subgraph "⚙autogenarated, <br>read-only modules"
RO["🦉<br>import-module.owl"]
end

RO -- is annotated by --> CUS
CUS -- references IRIs of --> RO
OEO -- references IRIs of --> RO


subgraph "👤 user-editable <br> read-write modules"
    OEO["OEO-ontology"] 
    CUS["🦉<br>customization.owl"]
end

This approach allows to:

• update each import-module independently + autogenerated (as customizations only reference IRIs)
• creating the newest ro-module etc. upon release keeping the source ontology and OEO in sync

Elements to be implemented

Clean-up + Refactoring

• [ ] create list of terms in iao-module
• [ ] update list of terms in ro-module
• [ ] update IRI used in scripts for annotations 💬
• [ ] remove foaf from ro-module 💬

Documentation

• [ ] wiki entry of ROBOT extraction functionalities

[l-emele]

What does 🚧 mean?

[markus-rothkoetter]

Ah sorry, "work-in-progress" the WIP part got lost when writing. I'm preparing the list of requirements for the reworked process currently. So, the issue description might change a few times.

[l-emele]

Of course, a newly opened issue is work in progress. No need to document this in the issue title. If you want to document the status of the issue, please use this function:

[markus-rothkoetter]

I might have explained it not clearly:

The description of the issue is work in progress, ergo, it is kind of an issue draft. (AFAIK this is not captured in one of the issue-tags)

I intended to mark this issue as irrelevant to others as long as I haven't finished the description.

[markus-rothkoetter]

@jannahastings I think, I've come up with a concept satisfying most requirements for the rework of importing ontology terms. Only the issue description sections "Key questions to solve" and "Ideas for solution" are relevant, currently. Could you please have a look and provide your opinion concerning feasiblity / potential pitfalls?

The other sections just provide detailed references + potential implementation details NOT relevant, yet ;)

[jannahastings]

It is based on separating all edits (term-tracker + axioms) concerning imported terms into a file customization.owl (This could also be the oeo-shared, but in terms of separation of concerns a dedicated file is better in my opinion.)

What about something like iao-extracted.owl paired with iao-edit.owl (for each module)?

[jannahastings]

• How do we prevent the usage of relations which were meant as "grouping-only" by the creators of external ontologies?

I am not sure about this: I am not sure that "grouping-only" is a valid concept. If there is a relation, it should be usable if it applies and is the best one for the knowledge being represented. Of course, we can favour more specific relations but I wouldn't preclude using higher up ones if they apply?

[markus-rothkoetter]

What about something like iao-extracted.owl paired with iao-edit.owl (for each module)?

I really like the idea of iao-extracted.owl as a meaningful name.

From the user perspective I'd like to combine all edits into one .owl-file as this makes the interface less complex for the use case:

• CI complains about wrongly placed axioms (in an ...-extracted.owl ➔
• user gets info how to move axioms ➔
• user Right-Clicks axiom in Protégé ➔
• user selects Move axioms to ontology ➔
• user selects -edit.owl as destination

The last step lists all modules when the oeo.omn is opened, resulting in a potentially complex looking list. If there was only one "extracted-edit.owl" (or similarly named file), this would be more user-friendly in my opinion. (limiting options = limiting confusion)

In case someone with ontology expertise would like to restructure something, the file could be parsed/split/sliced/filtered quite easy. Does this make sense or are different -edit.owl-files better?

[markus-rothkoetter]

I am not sure about this: I am not sure that "grouping-only" is a valid concept. If there is a relation, it should be usable if it applies and is the best one for the knowledge being represented. Of course, we can favour more specific relations but I wouldn't preclude using higher up ones if they apply?

I consider the concept of "grouping only" as not that user-friendly/understandable, too. Don't know what the creators had in mind, but they state it explicitly e.g. here.

In case a dependency creator changes things (not being aware of the user's use case or thinking that the use case was excluded explicitly), the dependend product potentially breaks.

In other fields, I considered it good practise to rely only on things with a "guaranteed" use-case. Lacking experience in the ontology field, I cannot assess the risk or estimate the effort needed to fix things used by a broader audience.

So, you'd take the risk and treat the relations like any other?

[markus-rothkoetter]

Wrap-up from OVGU-meeting:

I'll create a proof-of-concept script with one import-edits.owl-file in one of the next two weeks.

Concerning the "read-only"-properties, I'm going to reach out to the ro-developers and what their intention was. (general limitation because of ... vs limitation which applies only for their project scope) Until then, everything will remain as it is.

[stap-m]

From #1268 further steps:

• duplicating the process for iao-module using the same unified oeo-import-edits-file for custom axioms
• cleaning up oeo-shared concerning all custom axioms related to imported concepts + properties ~~creating a wiki-entry on how to use the scripts for generating updated ro-extracted + iao-extracted-files~~ (already done, see https://github.com/OpenEnergyPlatform/ontology/wiki/Modules-of-the-OEO)

[l-emele]

I added this issue to the 2.0.0 release milestone. To me it is unclear,

• what already has been done,
• what still has to be done,
• and what gets irrelevant with the restructuring of the oeo-modules and the new imports.

[stap-m]

We updated the import processes for ro, iao, uo and omo, which are all imports (besides bfo). Therefore, I see this issue as done and I close.