INCATools / ontology-development-kit

Bootstrap an OBO Library ontology
http://incatools.github.io/ontology-development-kit/
BSD 3-Clause "New" or "Revised" License
219 stars 54 forks source link

Imported ontologies not empty despite terms files empty #849

Closed pfabry closed 1 year ago

pfabry commented 1 year ago

When using default module_type (smle as I understand) some ontology_import.owl files includes some classes and properties while none has been specified in the ontology_terms.txt. For example, an import configuration such as:

import_group:
  products:
    - id: bfo
    - id: omrse
    - id: omo
    - id: ro

will produce imports files of various size: omo_import.owl (26 ko), omrse_import.owl (260 Ko), and ro_import.owl (188 Ko) despite all corresponding terms.txt being empty. BFO does not seems to be affected by this (bfo_import.owl is basically empty), but all other ontologies tried (pato, envo, ecto, obi) will have a _import.owl files including some of its content. using module_type: filter prevent this behaviour. All ontologies mirrored OK on local repository. Example here: https://github.com/pfabry/ODKTestImports/pulls

matentzn commented 1 year ago

@pfabry thank you for the inquiry.

I made some comments on your PR. Basically you are hitting some of the inherent limitations of the SLME approach. SLME guarantees that all logical axioms need for reasoning are imported, but some axioms, including those that contain individuals, are considered "global" and are always imported. This is a formal limitation of SLME. Read more here: https://robot.obolibrary.org/extract#syntactic-locality-module-extractor-slme.

Let me know if I can help further!

pfabry commented 1 year ago

Thank you for the answer and the enlightening comments in the PR. Prior to using ODK I used ROBOT extract script where I systematically excluded individuals so that explains why I had not encountered this behavior before. A small question of GitHub etiquette : who should close this issue ?

matentzn commented 1 year ago

I always let the users close, because I don't want to presume that there issue is solved.. I find framework side issue closing without confirmation personally a bit passive aggressive, but I see it makes sense in high velocity environments.

pfabry commented 1 year ago

Issue resolved: use slme_individuals: exclude