Knowledge base and constraints

[Grégoire Montcheuil]

Dear INCEpTION Community,

I want to configure a project where a KB based feature appear only when another feature has a special value.
B.e. a NER task where one of the category is 'Medical terms' and in this case we have a second feature, linked to a KB (say SNOMED CT, ICD-10, ...).

It seems the solution is a constraint for conditional feature... but when we look the constraint grammar, we have to list all possible values for the constrained feature ( <restrictions>)... what could be very fastidious for a KB.

(1) Is there any special syntax for the constraints to restrict the values to a full KB (or a partial sub-set of the KB) ?

(2) Otherwise, is there another solution for our set-up ?

Furthermore, we try a constraints like `NER { category = 'Medical terms' -> medical_kb = ""; }` ... but when we look in the Layers panel at the options for our KB feature, any of the "Required" and "Shown only when constraints apply" checkbox appear.

(3) Does anyone know why this two options are missing in the case of a KB feature ?

Nota: they both appear on the (a little outdated) screenshot in the documentation for the version we used (39.5).

Thanks in advance,

Grégoire

[Richard Eckart de Castilho]

Hello Grégoire,

> On 18. Feb 2026, at 12:02, Grégoire Montcheuil <gregoire....@gmail.com> wrote:
>
> I want to configure a project where a KB based feature appear only when another feature has a special value.
> B.e. a NER task where one of the category is 'Medical terms' and in this case we have a second feature, linked to a KB (say SNOMED CT, ICD-10, ...).
>
> It seems the solution is a constraint for conditional feature... but when we look the constraint grammar, we have to list all possible values for the constrained feature ( <restrictions>)... what could be very fastidious for a KB.
> (1) Is there any special syntax for the constraints to restrict the values to a full KB (or a partial sub-set of the KB) ?
> (2) Otherwise, is there another solution for our set-up ?

The constraints code currently is only able to re-order a tagset.
Values matching the constraints are sorted first, then the other values.
This only works for string features with tagsets.

Allowing constraints for KBs would require a new implementation.
It is not particularly clear what this implementation would need to look like.
Probably a simple thing like defining a regex over the concept ID would not be sufficient.
Probably some like of property matching rules over the knowledge base would be required.
Maybe this matching would need to interact with the queries to the knowledge base itself.

So while this is an interesting feature, it is a bit of effort and it requires getting a
clearer picture of what is actually needed.

Feel free to describe your scenario in more detail in a feature issue:

https://github.com/inception-project/inception/issues/new?template=feature_request.md

> Furthermore, we try a constraints like `NER { category = 'Medical terms' -> medical_kb = ""; }` ... but when we look in the Layers panel at the options for our KB feature, any of the "Required" and "Shown only when constraints apply" checkbox appear.
> (3) Does anyone know why this two options are missing in the case of a KB feature ?
> Nota: they both appear on the (a little outdated) screenshot in the documentation for the version we used (39.5).

Same explanation as above :) The reason why these options are in the (outdated) documentation
is that for some time, the logic that would hide these options when they are not applicable was
missing. Since, this has been fixed, and the options are now only visible when applicable
(hopefully).

-- Richard

[Grégoire Montcheuil]

Dear Richard,

Thank you for your rapid and enlightening response.

I discovered the constraints in a project that use them (mainly) to show/hide optional features

 and it's interesting to find out that the main purpose of the constraints is "reorder the choice of tag" (as it well said in the first line of the section).

So I understood show/hide optional features using a constraint seems more to an hack.

I hope I will rapidly find the time to open a feature request with the adequate description.

I also understand that the iterative construction of INCEpTION leads to this mismatch between (old) documentation and more recently coded logic...

However, more I think about that and more I do not understand why the logic is to exclude this two options for a KB.

(a) Why we cannot "Require" a KB feature ?

(b) If the constraints are here to reorder, putting first some values but without forbid the other values of a tagset...

 even without the complexity of expressing sub-queries of the KB, I suppose we can do so with a KB feature, i.e. use constraint(s) to put first a couple of values ?

(c) And if it is not totally illogical to use a KB feature on the right side of a constraint, perhaps we can also "Shown [it] only when constraints apply" ?

Best regards,

Grégoire

[Richard Eckart de Castilho]

Hello Grégoire,

> On 19. Feb 2026, at 16:13, Grégoire Montcheuil <gregoire....@gmail.com> wrote:
>
> I discovered the constraints in a project that use them (mainly) to show/hide optional features and it's interesting to find out that the main purpose of the constraints is "reorder the choice of tag" (as it well said in the first line of the section).
> So I understood show/hide optional features using a constraint seems more to an hack.

At the time it was a convenient way of adding the ability to show/hide features because we already had the rules engine for the constraints and this allowed us to re-use the rules engine for showing/hiding with minimal work.

> I also understand that the iterative construction of INCEpTION leads to this mismatch between (old) documentation and more recently coded logic...
> However, more I think about that and more I do not understand why the logic is to exclude this two options for a KB.
> (a) Why we cannot "Require" a KB feature ?

I think you are right, this seems to be a bug. The option should be there. I'll look into that.

https://github.com/inception-project/inception/issues/5895

> (b) If the constraints are here to reorder, putting first some values but without forbid the other values of a tagset... even without the complexity of expressing sub-queries of the KB, I suppose we can do so with a KB feature, i.e. use constraint(s) to put first a couple of values ?

In principle yes, but the code that handles constraints/tagsets is separate from the code that handles concept features. So while the general idea could be made to apply, it would require re-implementing the constraints logic for concept features. The existing implementation for tagsets would not be easily applicable (in particular if one would want to get away from having to list every concept URI explicitly and go more towards supporting some kind of pattern/regex or something even more sophisticated).

> (c) And if it is not totally illogical to use a KB feature on the right side of a constraint, perhaps we can also "Shown [it] only when constraints apply" ?

Same problem as above. It requires porting the constraints idea to concept features.

It is not impossible to build this, but it is not done in a 1-2 hours either.
And so far, it has not been done.

Cheers,

-- Richard