Should linkml generate linkml optionally materialize default_range into explicit slot ranges?

[turbomam]

Context

When a schema has default_range: string and slots without explicit range:, the linkml generate linkml output preserves this implicit inheritance - slots still lack explicit ranges.

Example input:

default_range: string
slots:
  my_slot:
    description: A slot without explicit range

Output from linkml generate linkml:

default_range: string
slots:
  my_slot:
    description: A slot without explicit range
    # still no explicit range

Problem

This causes issues for downstream consumers who transform the schema. For example, a yq transformation like:

# Convert all string ranges to TextValue
(.. | select(. == "string")) |= "TextValue"

Only affects slots with explicit range: string, not slots that inherit from default_range.

Real-world example: GSC MIxS v6.2.2 has 177 slots (out of 1059) without explicit range that rely on default_range: string. See GenomicsStandardsConsortium/mixs#1091

Proposal

Add an option to linkml generate linkml (and possibly other generators) to materialize default_range into explicit range values on slots that lack them:

linkml generate linkml --materialize-default-range schema.yaml

This would be similar to how --materialize-patterns works for structured patterns.

Related Issues

• SchemaView.induced_slot_range does not use the default range of the schema #3019 - SchemaView.induced_slot_range does not use the default range of the schema
• SchemaView slot ranges, default ranges, and monotonicity #2902 - SchemaView slot ranges, default ranges, and monotonicity
• ifabsent_processor does not handle default_range #2522 - ifabsent_processor does not handle default_range
• Materialize structured patterns in all relevant generators #1557 - Materialize structured patterns in all relevant generators
• make structured_pattern materialization an optional part of all generators #2158 - make structured_pattern materialization an optional part of all generators

Questions

1. Is this the right approach, or should the expectation be that schema authors always use explicit ranges?
2. Should this be a flag on individual generators or a more general SchemaView/materialization option?
3. Are there other inheritable metaslots that should also have materialization options?