Is there any reason to use range_expression when we have boolean expressions

[cmungall]

Question from @ialarmedalien in slack:

The current LinkML model has a slot range_expression, which is defined as “A range that is described as a boolean expression combining existing ranges” and with the comment one use for this is being able to describe a range using any_of expressions, for example to combine two enums Is this actually in use anywhere or has it been replaced/superseded by using linkml:Any and any_of / exactly_one_of / etc.?

[cmungall]

range_expression allows for a kind of "path" syntax, allowing nesting of constraints

Let's say we have a core schema:

slots:
  numeric_value:
    range: float
  unit:
    range: string
classes:
  QuantityValue:
    slots: [numeric_value, unit]

now let's say we want to introduce a slot depth whose range is the (generic) QuantityValue, but we want to constrain it such that depth.unit == "m".

This is only possible with range_expression

slots:
  measurement:
    abstract: true
    range: QuantityValue
  depth:
    is_a: measurement
    range_expression:
      slot_conditions:
        unit:
           equals_string: m

Arguably a dedicated path syntax for constraints would be cleaner for this example. And arguably the metamodel should allow the range of range to be any_of an expression or a named class. But this design fits most cleanly into the existing structure

HOWEVER, range_expression is not yet implemented, but this is straightforward for jsonschemagen: #2792

[ialarmedalien]

I came across range_expression whilst looking through the model for anything that might influence the range of a slot and which should thus be taken into account when implementing linter checks.

The def and comment suggest that it should be possible to do something like:

attributes:
  unit:
    range_expression:
      any_of:
        - DistanceUnitEnum
        - VolumeUnitEnum
        - MassUnitEnum
  value:
    range_expression:
      any_of:
        - float
        - integer

but the use case demonstrated above suggests otherwise...?

This brings up two issues:

• Definitions need to be more descriptive and (ideally) include examples, especially for terms from the model that are not in common use; I usually search the linkml repos/biolink/NMDC/MIxS to see if there's an example, but it should really be there in linkml-model and/or accompanying documentation.

• It is difficult to know where in the linkml/linkml-runtime libraries the most complete implementation of the schema features exists. The autogenerated *Definition classes have the appropriate attributes but interpretation and implementation are up to the user. The SchemaViewer class is used in a lot of places in the codebase, but I don't know if it can be relied upon to correctly interpret more complex aspects of the schema, like range_expression[1]. Some schema features aren't even relevant to a package like SchemaViewer; they're only relevant to transformers or generators, etc.

I haven't yet explored the compliance tests and I assume that they cover some of this (even if we don't yet have the magical schema feature implementation table that we all dream of!).

[1] Well, this discussion obviously establishes that range_expression is not implemented. 😉