IHTSDO / snomed-owl-toolkit

The official SNOMED CT OWL Toolkit. OWL conversion, classification and authoring support.
Other
92 stars 19 forks source link

NPE when registering acceptability of inactive/missing descriptions #31

Closed apeteri closed 4 years ago

apeteri commented 4 years ago

In https://github.com/IHTSDO/snomed-owl-toolkit/issues/30#issuecomment-559520810, @kaicode writes:

This line is causing the null pointer: https://github.com/IHTSDO/snomed-owl-toolkit/blob/master/src/main/java/org/snomed/otf/owltoolkit/taxonomy/SnomedTaxonomy.java#L259

This indicates that there is an active language reference set entry for a description which does not exist or is not active. [...] they may be referencing content which is active January but no longer active in the July package you are using.

Could this be a "soft" error instead, that is reported with the UUID/effective time of the offending reference set member? It seems like in the current release, such exceptions result in dialect detection being broken for exported RDFS and SKOS labels (they still get tagged with the language code of the description, eg. "en", but not with eg. "en-us" if the US refset is the one having problems).

This can happen if users want to take a look at the OWL representation while doing an upgrade, where references to inactive components might not be fully cleaned up.

kaicode commented 4 years ago

Hi @apeteri, thanks for spotting this and bringing it up. Yes, great idea. The exception handling when loading RF2 files needs some improvement here because as you say the thread loading a reference set file can just stop when an exception is thrown. We should probably check if the description exists and just log a warning if it doesn't?

Do you have capacity to write a pull request for this change, assuming that it's impacting something you are looking at? If not no problem, I should get to it in a few days.

Kind regards, Kai

kaicode commented 4 years ago

Not sure if this is a bug or an enhancement. I intended the toolkit to only work with versions of modules which are already validated as being dependent on each other and consistent, but on the other hand being lenient and reporting warnings is good 😄.