Comments (10)
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.
from snowstorm.
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?
from snowstorm.
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?
from snowstorm.
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.
from snowstorm.
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.
from snowstorm.
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?
from snowstorm.
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).
from snowstorm.
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.
from snowstorm.
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.
from snowstorm.
@dkincaid Thank you for the positive feedback!
from snowstorm.
Related Issues (20)
- Refset bulk update HOT 2
- Unable to load SNOMED CT into Docker instance HOT 3
- HTTPS Configuration for Apache Server and Swagger HOT 6
- CORS issue with Snowstorm despite updating nginx setup and application.properties HOT 1
- Loading data: Failed UK Monolith RF2 SNAPSHOT import on branch MAIN (Resolved) HOT 10
- SNOMED CT Browser makes API request without branch HOT 4
- Request for Clarification on Unlimited Pagination for {branch}/concepts Endpoint HOT 2
- Issue with updating DependantVersionEffectiveTime in CodeSystem Version HOT 4
- Own extension in FHIR CodeSystem HOT 2
- Clean install on Kubernetes failes HOT 13
- Missing @ApiResponse causes issues when trying to generate client HOT 1
- No release package is set for version HOT 2
- Import is getting rollbacked with 8.2.2 jar file HOT 10
- Loinc Codes Not found After uploading FHIR Terminology package HOT 5
- ECL versión supported HOT 2
- Error for local language code sent by browsers in Latin America HOT 5
- Expanding Valueset on extension work with ECL of parent branch (SNOMED CT India DRUG Extension) HOT 3
- Import error using docker setup for SnomedCT_InternationalRF2_PRODUCTION_20240701T12 HOT 3
- Write With Authentication Mode HOT 4
- Python access leads to IP blacklisting? HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from snowstorm.