Provide autocomplete for a subtree/subset of an ontology/terminology

[johannes-darms]

The NFDI4Health metadataschema (https://repository.publisso.de/resource/frl%3A6450625) defines subtrees and subsets of ontologies to be used for certain fields. Currently the widget nor the OLS API allows search or autocomplete for a subset of an ontology.

As a developer
In oder to allows users to use search and autocomplete within a subset of an ontology
I want to specify a subset/subtree to limit the scope of the autocomplete/search

Example:
"The values originate from the following sources: 1) 10 types of cancer with the highest incidence in Germany, by gender, based on 2017/2018 German cancer registry data (RKI, Zentrum für Krebsregisterdaten, https://www.krebsdaten.de/); 2) 10 cardiovascular diseases with highest mortality in Germany in 2020 (www.destatis.de).
All values follow the classifiction system ICD-10 (WHO's International Statistical Classification of Diseases and Related Health Problems, 10th Revision (ICD-10), https://icd.who.int/en)."

"Lower level ICD-10 (https://icd.who.int/browse10/2019/en), with autocomplete"

"The values originate from the WHO's International Statistical Classification of Diseases and Related Health Problems, 10th Revision (ICD-10). The list: Certain infectious or parasitic diseases (I)
Neoplasms (II)
Diseases of the blood or blood-forming organs and certain disorders involving the immune mechanism (III)
Endocrine, nutritional and metabolic diseases (IV)
Mental and behavioural disorders (V)
Diseases of the nervous system (VI)
Diseases of the eye and adnexa (VII)
Diseases of the ear or mastoid process (VIII)
Diseases of the circulatory system (IX)
Diseases of the respiratory system (X)
Diseases of the digestive system (XI)
Diseases of the skin and subcutaneous tissue (XII)
Diseases of the musculoskeletal system and connective tissue (XIII)
Diseases of the genitourinary system (XIV)
Pregnancy, childbirth or the puerperium (XV)
Certain conditions originating in the perinatal period (XVI)
Congenital malformations, deformations and chromosomal abnormalities (XVII)
Symptoms, signs and abnormal clinical and laboratory findings, not elsewhere classified (XVIII)
Injury, poisoning and certain other consequences of external causes (XIX)
External causes of morbidity or mortality (XX)
Factors influencing health status and contact with health services (XXI)
Other
Not applicable
Unknown"

[johannes-darms]

Is there a chance that we somone can work on this issue?

[Pooya-Oladazimi]

In ols3 and 4, only the api/select/ endpoint (jump to) supports such filter: https://service.tib.eu/ts4tib/swagger-ui.html#/search-controller/filteredSelectUsingGET

[johannes-darms]

Nice, so we could use the allChildrenOf property, right? This would be a fairly simple addition to the autocomplete widget, or is it more complicated?

[Pooya-Oladazimi]

Yes, it can be implemented.
@jusa3 what do you think?

[jusa3]

It should already work. @johannes-darms @Pooya-Oladazimi

https://ts4nfdi.github.io/terminology-service-suite/comp/latest/?path=/docs/react_autocompletewidget--docs

By adding the parameter allChildrenOf (with a list of IRIs for the entities you want to search under):
E.g.ontology=mesh,snomed&type=class&collection=nfdi4health&fieldList=description,label,iri,ontology_name,type,short_form&allChildrenOf=http://snomed.info/id/160670007,http://purl.bioontology.org/ontology/MESH/D016640

I don't quite understand your example with ICD10...

[Pooya-Oladazimi]

@jusa3
Oh true. I forgot about that option text field. Maybe we can make this one a separate component input that takes a list of iris since this is a requirement that I often hear from different communities.

[jusa3]

Sure, if you have time :)

[johannes-darms]

Sounds great, thanks. Can we also provide a set of custom options that should be part of the UI and selectable, but not included in the terminology lookup service. For example, we need 'Other', 'Not applicable' and 'Unknown'.

As an explanation, we have a data entry form where users should select a concept from an ontology or, if no option is suitable, state the reason why this property cannot be filled in, i.e. explain the missing.

[Pooya-Oladazimi]

@johannes-darms

I am not sure whether this scenario fits this component or not. This widget is an autocomplete but the behaviour you are describing is more like a drop-down selection. Having "Other" or "not selected" does not suit an autocomplete box in my opinion.

Regarding the example you provided, you can tell the user this is not a mandatory field but in case you want to leave it empty, please provide some explanation why. or something like this.

[Pooya-Oladazimi]

Nice, so we could use the allChildrenOf property, right? This would be a fairly simple addition to the autocomplete widget, or is it more complicated?

@johannes-darms

I would like to know what is the difference between childrenOf and allChildrenOf properties? and which is more useful in your viewpoint?

[johannes-darms]

@johannes-darms

I am not sure whether this scenario fits this component or not. This widget is an autocomplete but the behaviour you are describing is more like a drop-down selection. Having "Other" or "not selected" does not suit an autocomplete box in my opinion.

Regarding the example you provided, you can tell the user this is not a mandatory field but in case you want to leave it empty, please provide some explanation why. or something like this.

I see your point. However, we, and potentially others, will use the widgets to encourage people to add semantic concepts to a metadata record. In many cases, the set of allowed options (i.e. children of a concept) is insufficient or inappropriate. As a result, no element is selected and we store an empty value (i.e. no information) and we do not know why no information is provided. Information about why a property is missing is often quite useful, so the options "Other", "Not applicable", "Unknown" are there to encode this. (Hopefully we will be using semantic concepts from these in the near future....) To summarise: The set of IRIs that should be considered by a user are: missing_iri - a set of IRIs (to encode missing values), allChildrenOf - a set of key-value pairs (tuples) of an IRI as key and the corresponding set are all children including transitive ones that are children of the key. Obviously the set has to be computed and won't be provided by a client. Having defined the set of IRIs, we consider different ways of presenting them to the user. Which one is best is rather subjective, but we can still refine some requirements:

• In several cases, such as the one above, the list of items is too large for a simple drop-down menu and a search/autocomplete feature is needed.
• The autocomplete cannot be computed within the JavaScript client due to possible large result sets (e.g. a higher level concept of GO with thousands of children).

Do you agree with the set definition and the derived requirements?

For the visualisation I have these three options in mind:

• One option would be an autocomplete with checkboxes to select "not applicable", "unknown". "Others" could be an option to be displayed within the autocomplete if nothing matches.
• Another could be an autocomplete that displays text below the completion (i.e. the input is empty) explaining that if nothing matches, the following missing options can be selected.
• Another could be an autocomplete where those missing items are just treated as 'normal' options.

One could argue that this advanced requests are details that a client would have to implement themselves, and that widgets only provide the basic building blocks. I would argue that these more complex components (e.g. autocomplete with checkboxes on the side) are the real benefit of widget library.

[johannes-darms]

I don't quite understand your example with ICD10...

In this example the user should be offered with all concept of parts of a tree. In ICD this means only two or three digit codes should be used, but only those which are children of the given list. "Neoplasms (II)", should only be coded by (there are many more options within the tree of Neoplasms cf. Neoplasms ):

[jusa3]

Subtree implementation will be discussed in the next weekly: Should we define input properties if they are defined as parameter already?

Custom option implementation is discussed in this issue