Autocomplete: custom options

[jusa3]

To discuss in our weekly

Provide a set of custom options that should be selectable, e.g. 'Other', 'Not applicable' and 'Unknown'.

Use case: 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 (to avoid storing an empty value (i.e. no information) and we do not know why no information is provided).

See #14 (comment)

[jusa3]

This use case is needed when autocomplete is used in a form to define keywords, for example. The purpose of a reusable widget is to be used in different kinds of use cases, especially for linking semantic concepts; this new feature wouldn't make it more complex, but it would make it more widely applicable IMO.

I see the following realisation (based on #14 (comment)):
Creating two checkboxes for "not applicable" (if key terms are not allowed/needed) and "unknown" (if the user doesn't know what to enter). The option "others" (if no matching key term is found in the autocomplete) could be displayed within the autocomplete drop down if nothing else matches.

In a first implementation, the input property will be the IRIs of the three concepts, provided they are represented in the underlying terminology service database (the selected API). In a second implementation (when the TS4NFDI Gateway is available and value sets are implemented), a value set can be created and applied.

[jusa3]

The feature of implementing the options without underlying value sets was declined. Reason: The TS4NFDI Service Suite should provide standardized metadata. Defining own identifiers for the options wouldn't support this goal.

If the TS4NFDI Gateway will be implemented and used for the widgets, and the Gateway will support creating value sets - then this custom options enhancement would be an option.

[rombaum]

This feature could be solved via an entity set which should be provided by the TS4NFDI Service Portal and the API Gateway in the future. For this it would be interesting which semantic concepts should be choose for the three semantic concepts. It could be combined solved in an incubator project with this issue: #15 . Before we could start such an incubator we need collection in the API Gateway. This should be solved at least in Q2/25. So we could try to do an incubator starting in Q3/25. We will create an issue in the Gateway repository and close this issue afterwards.

label	possible IRIs
Other	http://purl.obolibrary.org/obo/OPMI_0000028
Not applicable	?
Unknown	http://purl.obolibrary.org/obo/NCIT_C17998