search

aehrc / fhir-owl

Transforms OWL ontologies into FHIR code systems.
Other
20 stars 12 forks source link

Question about design (content retention) #11

Closed joeflack4 closed 11 months ago

joeflack4 commented 1 year ago

I was looking at the documentation for fhir-owl and also looking at some of the output it generates and comparing with obographs. The big difference I saw is that by default, fhir-owl leaves out most content/properties/relationships unless you specifically ask it to include something (and currently, there are a lot of possible properties and relationships that are not supported, because they have to be specifically added to the CLI and implemented). On the other hand, Obographs seems to transform everything in OWL to a JSON representation.

My thought was that this is a preferable approach: to convert all the content we possibly can from OWL to FHIR. I'm wondering if fhir-owl has chosen not to do this specifically as a design decision, or if there is another reason why the output is currently much more minimalistic (i.e. it was easier to design fhir-owl the way it currently is for MVP purposes)?

Another reason I'm asking this is because my team has a use case for getting OWL/OBO into FHIR, but we would like to convert as much content as possible to FHIR, adding extension elements where necessary. I'm wondering if the fhir-owl team is open to moving the design from the current, more minimalistic approach, to a more "everything goes" style?

joeflack4 commented 1 year ago

@chrisroederucdenver FYI. Feel free to add anything I missed~

andrewpatto commented 1 year ago

Adding a +1

I would also like some 'extra' fields out of the source OWL for HPO (such as some of the useful 'comment' fields and extra length definitions) Though I think I'd be happy if there was some CLI switches that specifically picked attribute->properties for mapping

lawley commented 1 year ago

We went for a minimalistic approach because we've seen that different OWL ontologies take very different approaches and there's no easy one-size-fits-all set of defaults. Also, it's easier to add stuff in rather than take it away from an interoperability / backwards compatibility perspective. The other issue is the potential size of the resulting CodeSystem. Finally, until you're actually transforming a specific Ontology it's not always clear how best to map things.

@andrewpatto we'd definitely be open to a pull request for some kind of generic attribute -> property mapping function.

joeflack4 commented 1 year ago

Hey @lawley. Great to hear back! I think that makes a lot of sense. I don't have that much experience with working with different OWL ontologies yet, so it may very well be that I will soon see first-hand these different structural issues you speak of. I'm thinking that I will continue developing my tool which has the opposite design in this respect. If my tool reaches a certain level of maturity, I'm wondering if you'd like to link to each other's repositories? And maybe have some information in the README.mds as to what other tools are available and comparing their differences. Right now I'm just thinking about aehrc/fhir-owl and what I'm working on which will probably go into jhu-bids/owl-on-fhir. This could be just a few sentences about the minimalistic vs everything-goes approaches.

Feel free to close this issue as well whenever you like, as you have answered my initial question.

lawley commented 11 months ago

As requested by ticket author.