Importing Subclass Object Properties

[AsaphHall]

Dear ODK-Team,
i've successfully created a repository with the odk + .yaml file and managed to import ontology terms from the Basic Formal Ontology (BFO) and the Information Artifact Ontology (IAO) via term files. As the IAO uses the BFO as its Top-Level-Ontology it would be great if the IAO-Terms would be integrated into the BFO hierarchy (at least those that have are direct Subclasses of BFO Terms, in my case that would be the IAO_0000030 (information content entity) which is a SubClassOf the BFO_0000031 (generically dependent continuant) . I cannot figure out how to import the rdfs:SubClassOf Property. I tried to include the rdfs:SubClassOf Property in the 'import group -> annotation properties' of the .yaml file, that did not work so far. Do you have any advice on how to import classes including the SubClassOf Relations?

[matentzn]

I cannot figure out how to import the rdfs:SubClassOf Property. I tried to include the rdfs:SubClassOf Property in the 'import group -> annotation properties' of the .yaml file, that did not work so far. Do you have any advice on how to import classes including the SubClassOf Relations?

You do not need to specify subclassof as a property to include - this is done automatically. Whether the correct axioms are imported depends on the module type you are using. Can you share a link to your ODK config (or paste it here) and tell which exact ontology has the subclass axoms you want?

[AsaphHall]

Thank you for your reply. I think it might be the module_type: filter then? I dont want to import the whole IAO, just some terms (e.g. IAO_0000030, which is imported. Its just missing the rdfs:SubClassOf).

Ill add the lines of my ODK config file (without the first 4)

`git_main_branch: main
release_artefacts:

• base
• full
• simple
  primary_release: full
  export_formats:
• owl
• obo
• json
  import_group:
  annotation_properties:
  • IAO:0000111
  • IAO:0000112
  • IAO:0000115
  • IAO:0000116
  • IAO:0000117
  • IAO:0000119
    products:
  • id: bfo
    module_type: filter
  • id: iao
    module_type: filter
    robot_java_args: '-Xmx4G'
    documentation:
    documentation_system: mkdocs`

[matentzn]

Yes, filter module is the problem. You might be able to work around this by adding the respective BFO terms directly to the IAO terms file. Or - and I have never tried this with any ODK repo - you might be lucky using base_merging approach which first merges all the imported ontolofies into one before extracting modules.

https://github.com/obophenotype/cell-ontology/blob/4b473d870205fdeb23ff79880250ff6374935977/src/ontology/cl-odk.yaml#L60

Its a bit more complicated but I can also walk you through this - just not sure it can work with filter, so try the first thing first.

[AsaphHall]

Thank you, ive been tinkering around a little bit but did not manage to successfully import the IAO terms with said approaches. After adding the BFO terms to the IAO terms file only three of the terms (BFO_0000015, BFO_0000019, BFO_0000031) were imported (those were also mentioned in the iao_import.owl file in the imports folder), the remaining ones were deleted (there are 41 BFO terms in my IAO term file that got imported correctly when importing the bfo on its own beforehand). The iao.owl file in the mirror folder is complete and does contain all of the 41 BFO terms i tried to import. Afterwards i tried to added use_base_merging: TRUE to the yaml file but that ran into an error for me. I additionally tried to import the entire IAO just to see if it would work by itself (without module_type: filter or the BFO) and i still ended up with only a fraction of the IAO being imported into the ontology.

[matentzn]

OK, lets do it step by step. I am assuming you are part of NFDI or some such and are trying to migrate https://github.com/AsaphHall/tfsco to ODK based on a recommendation by @StroemPhi or someone else?

1. For us to help you effectively it would be good if you could send us a link to the PR where you do the work
2. Your plan of using BFO as a top level is sound and many groups do so, so no problem here
3. What you cant do is hoping to extract a logic preserving module on the one hand and selecting which terms exactly to import. It is either or: you pick a set of terms, and those exactly will be imported (using filter module) OR you use a logic preserving module like SLME. If you do the former, you have no guarantees that your reasoning is in any way complete - there are so many GCIs and so on scattered across RO and other ontologies which you would never catch with a manual approach, but you need them to be sure that you use BFO correctly. A typical example is that you want to make sure that an occurrent cannot be part of a continuant, and vice versa (one of the most frequent errors I see in my line of work).
4. If you absolutely MUST import a reduced set, you will have to create a custom import module in the tfsco.Makefile which (1) first extracts an SLME module (to get all the relevant axioms) and then apply a filter (to get rid of classes you absolutely dont want). We can help you with that but need to see the PR for that.

[AsaphHall]

Thanks a lot. Im not affiliated with the NFDI at the moment. Until now i did choose the pick-terms-you-need approach to reuse as many existing classes as possible and was aware of the potential risk of loosing some axioms by cherrypicking the terms and having to manually keep up with updates and developments in the ontologies the terms originate from. As ontologies like the CHEBI or CHMO contains thousands of classes importing the whole ontology did not seem like a suitable option either. The approach you mentioned in point 4 would be my preferred way going forward. I`ll set up a repository and get back to you.