Let class derivations declare an identity key for required identifier slots #342

When a target class declares an identifier slot, linkml-map warns if the spec derives no value for it (Required target slot 'id' has no derivation) and emits the record anyway. The output then fails validation against the target schema. In our BDCHM transforms that is roughly 6,400 of 6,641 class derivation blocks.

The workaround is to hand-write a uuid5() expression per block. That works — it is what our Visit, Participant, and Person derivations already do — but it puts identical derivation logic in thousands of places, and the thing being hashed is usually a key the spec has already spelled out in its reference slots. A MeasurementObservation is identified in practice by its participant, its visit, and its observation type; all three are already derived a few lines above.

Proposal: let a class derivation declare which of its derived slots constitute identity, and have linkml-map hash them into the identifier slot.

MeasurementObservation:
  populated_from: pht012853
  identity_from: [associated_participant, associated_visit, observation_type]

uuid5 already exists as an injected eval function, so the mechanism is in place; what's missing is somewhere to declare the key. The values are hashed after derivation, so the result is stable across runs, independent of row order, and unaffected by chunking or parallel execution.

The reason this should be declared rather than inferred is that identity is not recoverable from the data. Whether a changed cell means "same entity, corrected" or "a different entity" is a modeling judgement, and no rule over the input can settle it. Hashing the whole record would be deterministic but would change the identifier whenever any value changed, which is the wrong semantics for a stable key. Declaring the key keeps that decision with the spec author while keeping the derivation in one place.

Two things worth settling in the design:

• Collisions are possible and meaningful. Two measurements of the same type for the same participant at the same visit would hash alike; sometimes that is correct, sometimes it needs a discriminator. Being explicit about the key at least makes the question visible per class.
• Nested derivations have the same problem. Our value_quantity blocks derive a Quantity, which also inherits a required identifier, so whatever shape this takes should be usable on nested class derivations too.

Happy to implement this if the approach seems right.