CodeSystems: OWL/OBO Ontologies

[chrisroederucdenver]

Overview

HPO is a separate ticket and will likely spearhead this work, but here's a ticket for the rest of them. Mondo, and what is used in OBO2OMOP. SO for the Genomics WG (edit)

Sub-task list

CodeSystem internal content

Implementation details and other considerations in: https://github.com/INCATools/ontology-access-kit/issues/369

• [x] 1. is-a hierarchy
• [x] 2. Relationships/edges
• [x] 3. Synonyms: exact
• [x] 4. Synonyms: Non-exact (broad, etc)
• [ ] 5. Synonyms: multi-labels same concept (@chrisroederucdenver has an example)
• [ ] 6. Axioms
  • [ ] 7. Blank nodes (RDF, not OWL? used to capture restrictions, relevant to FHIR? relevant to Jan?)
  • [ ] 8. Cardinality constraints (not for FHIR CodeSystems, no reasoner, etc. to use them)

Ontologies

These checkboxes are for MVP versions of these, but it could take a lot longer to get all content represented, depending on unique complexity.

• [ ] 1. HPO (1, 2)
• [x] 2. #65
• [ ] 3. #32

Sub-task details

todo

Additional info

Major steps

1. Get working OWL to FHIR CodeSystem converter
2. Convert & load ontologies

3. 67 (Validate results w/ experts)

Related

• Converter implementation (OAK): https://github.com/INCATools/ontology-access-kit/issues/369
• TIMS OWL Transform Specification: https://docs.google.com/spreadsheets/d/1oMksaC78pc6ptVvuqifG0_rjMHS4rDffo15qLHmQaGw/edit#gid=0

[chrisroederucdenver]

need to clarify and distinguish between loading the CodeSystem from an Ontology and any related ConceptSet or ConceptMappings.

[joeflack4]

I know that Chris Mungall (@cmungall) said OBO is notoriously hard to parse. @cmungall: There's a way for us to convert this to a different format, like OWL, or right? Without any such conversion, I'd rate not easy.

For OWL, hopefully fhir-owl continues to do well. So far so good, but I haven't challenged it very much.

[chrisroederucdenver]

I thought the thinking was to load OBO ontologies from their OWL form...I'm assuming that exists for most.

[cmungall]

Of course you should just be building this in python with oak

But as you’re using Java the owl api will handle obo just fine

On Fri, Sep 30, 2022 at 6:43 PM Chris Roeder CUAnschutz < @.***> wrote:

I thought the thinking was to load OBO ontologies from their OWL form...I'm assuming that exists for most.

— Reply to this email directly, view it on GitHub https://github.com/HOT-Ecosystem/hapi-fhir-jpaserver-starter/issues/41#issuecomment-1264101690, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOL5LHBCROSBEOD5BW3WA5UIJANCNFSM6AAAAAAQWHZC4U . You are receiving this because you were mentioned.Message ID: @.*** com>

[joeflack4]

@cmungall For OWL -> FHIR we're gonna continue using fhir-owl unless we find there's an issue. You're saying that if we need to get an OBO ontology into FHIR, and there is no OWL available, we can use OAK? If so, then yeah, I would prefer that. I don't know where to begin doing this in Java and I'm better at Python anyway.

[joeflack4]

@chrisroederucdenver I added a list to the OP (original post) and added HPO to it. I think that will be my focus for this week. If we can add more ontologies that need to be added, that would be good (idk if that means we need to ask Melissa et al, or maybe you happen to know already).

FYI, there is a big 'wrapper issue' #4. I think most of the code systems in that list are not OWL-based, though, but HPO is on the list.

[cmungall]

You can ignore my comment about OAK if you are already embarked on doing all of this in java, as you seem to be. It's a shame we will have lots of duplication of code, as OAK is designed to be able to transparently access ontologies and vocabularies of all kinds

• OWL conforming to OBO guidelines
• OWL in the wild
• SKOS
• RDFS vocabularies
• obo format
• kgx
• obojson
• Bridge to any OntoPortal installation (including Bioportal, which has >1k vocabularies, including many closed clinical ones)
• Bridge to any OLS

As you are using java, then you can just use the OWLAPI to load:

• Any OWL syntax
  • this includes OBO-Format, which is an OWL syntax

But not OboGraphs JSON. You can use OAK as a pre-processing step to go from OnoGraphs JSON to OWL.

Alternatively you may be considering OboGraphs JSON as the default abstraction layer. In which case you can stay in java and convert anything the OWLAPI can handle to OboGraphs or you can just natively load OboGraphs

It's possible my comments are not helpful as I don't have any idea about the overall design for this project. The README is helpful to get things set up, but not other things. I will make an issue.

[joeflack4]

We are using Java for the server codebase. But for any external tooling that involves creating or transforming content, theoretically anything is game. Likely, I will use OAK or bioontologies for Obographs, which will be used as an intermediary to convert to CodeSystem JSON.

[chrisroederucdenver]

If you're considering sunk cost, the java server codebase in this repo is another group's effort. It also addresses the FHIR use-case which for now isn't necessarily the same as one that involves a terminology distro. My impression is that for the distro use-case there is a large body of OAK work to consider. I'm trying not to make this solely about implementation language as there are other sources of complexity in the world. The size or potential impact of relevant prior work should weigh heavily in the choices of supporting technology.

The use of this repo for issues is a legacy thing and a bit discordant. I agreed with continuing to use it in the short term for reasons that include minimizing disruption and distraction.

[mellybelly]

It seems like the ontology transforms could happen upstream using the OAK library, not mutually exclusive for the distribution/server goal.

[joeflack4]

@mellybelly OAK doesn't do this right now. Chris M asked me to add the feature (PR).

However, OAK doesn't provide anything that I can use yet to do this transformation. What I need is an intermediary Obographs converter. OAK's is currently not working. But even if it did, robot and bioontologies are already much more straightforward ways to do this. I discussed with Chris, and what I'm going to do is move this code to jhu-bids/owl-on-fhir as a standalone tool. Then, OAK can import this as a plugin.

Edit: I wonder if you just spoke with Chris. Coincidentally, he just pushed an alternate version of this today: https://github.com/INCATools/ontology-access-kit/pull/368

[cmungall]

Yes, and after this @joeflack4 and I chatted more on slack. I cleared up some misunderstandings about what libraries are needed (in fact there should be no need for preprocessing with robot or biointologies).

There is preliminary support for dumping to fhir CodeSystem json

https://github.com/INCATools/ontology-access-kit/releases/tag/v0.1.57

There are still many unpopulated fields, and some things for which mappings need to be clarified or made concrete. The OAK issue for future work is here: https://github.com/INCATools/ontology-access-kit/issues/369

[joeflack4]

The LinkML based approach that OAK uses is good. Just to clarify what I've been trying to express, I know that robot/bioontoogies is not needed for OAK; I just couldn't get OAK's obograph converters to work (it's actually the only part that I still don't understand how to work with). Bioontologies was just a very fast and easy way for me to get what I needed done last month.