Inferred vs. stated relationships for parents

[dkincaid]

I am seeing something odd when hitting the GET /browser/{branch}/concepts/{conceptId}/parents endpoint between "inferred" versus "stated". It may be my misunderstanding of something in SNOMED.

Working with the veterinary extension the following concept - 354541000009105 (Castrated male) is giving two completely different concepts as parents depending on whether I use "inferred" or "stated" for the form parameter.

For "inferred" it is returning concept 248153007 (Male). For "stated" it is returning concept 106106004 (Male reproductive finding)

I looked in the Relationship RF2 file in the veterinary extension and both of those is-a relationships are defined in there have different characteristicTypeId values. The 248153007 is 900000000000011006 (inferred relationship) and 106106004 is 900000000000010007 (stated relationship). So I think that explains why it is showing up the way it is.

So my question is does setting the form parameter to inferred only return the relationships with the explicit inferred relationship and not return any with stated and vice versa? If so, then doesn't this mean that in order to get all parents one would have to call this endpoint twice?

[rorydavidson]

I’m not aware of a use case where you would use both the inferred and stated relationships and so there should be no need to call the endpoint twice, and nor would you get results containing both stated and inferred as they are different views of the terminology.

However, the best explanation of the inferred and stated views can be found here - https://confluence.ihtsdotools.org/display/DOCGLOSS/inferred+view . Most implementations would be expected to use the inferred view, which is the result of a reasoner inferring relationships based on the stated view.

I hope this helps.

[dkincaid]

I still don't understand. Wouldn't I need to call it twice in order to get both the "stated" relationships AND the "inferred" relationships? Or are you saying that all of the "stated" relationships should appear in the "inferred" relationships too?

[rorydavidson]

Assuming your use case is to query the terminology and not edit or maintain the terminology, you should only be working with one, and never with both at the same time. So for the majority of uses of querying the terminology, you should only use the inferred view.

What is your use case?

[dkincaid]

My specific use case right now is to visualize a value set which is a subset of the SNOMED hierarchy. In order to do that I'm getting the parents of a concept that is in the value set in order to construct a graph. In the example I gave above for concept 354541000009105 (Castrated Male) there are two parents, 248153007 (Male) and 106106004 (Male reproductive finding). When I call the snowstorm getParents endpoint with form = "inferred" I get back just concept 248153007 (Male). When I call with form = "stated" I get back just concept 106106004 (Male reproductive finding). So in this case I have to call the endpoint twice in order to get all the parents.

What I'm trying to determine is if there is something wrong with snowstorm or with the veterinary extension or if this is expected behavior. At this time I don't know if there are other examples of this same phenomenon.

[rorydavidson]

An implementation should only be using one view and in your example, that would be the one through the inferred relationships. You will not need the stated relationships. You will find many examples where parents can be different in the stated and inferred view, but in any implementation, you should only be working with one.

Snowstorm is functioning as is expected with SNOMED CT and, without looking at it, I expect that the veterinary extension is also structured as expected. This is the expected behaviour.

[dkincaid]

I really appreciate your time. I understand now that I should be using the inferred relationships. But I'm still not clear on why in my example the one code that is a stated relationship is not showing up in the inferred relationship. That must be an error in the Veterinary Extension somehow, isn't it? I mean if there is an is-a relationship explicitly stated why would it not also be included in the inferred?

[dkincaid]

Here is an example of another problem. Code 28471000009108 (Intact Male) has the same two parents as my example above - 106106004 (Male reproductive finding) and 248153007 (Male).

In this case, "inferred" form returns zero concepts, but "stated" returns both of the parents. So in this case "inferred" doesn't return anything which is not possible in SNOMED (everything has at least one is-a relationship as far as I understand).

[rorydavidson]

No problem. To answer your question, stated and inferred is-a relationships are often not the same and the inferred view is driven by the concept model authored in the stated view. This also happens in the International Edition.

In the example you gave, the modelling elsewhere in the veterinary extension results in the reasoner inferring that the parent is Male instead of what had been authored specifically as a stated parent. As SNOMED CT is a semantic ontology, the use of a reasoner can identify more efficient parents and attributes based on how a hierarchy has been modelled.

However, you are very correct, there should always be an is-a relationship in the stated and inferred view of the ontology, so there may be something up with the veterinary extension.

[dkincaid]

Ok, I think I am starting to understand now. Thank you again for your time and for this tool. I have been looking for a couple years for a terminology service that was as easy to setup and use as this one is. I'll get in touch with the folks who maintain the veterinary extension and see what is up.

[kaicode]

@dkincaid Thank you for the positive feedback!