validate-spec should check class and slot references against source and target schemas

[amc-corey-cox]

`validate-spec` (#190) validates that a transformation spec is structurally correct (valid keys, nesting, types), but it does not check whether the spec references valid classes and slots in the source or target schemas.

Target schema validation:

• Class derivation names should exist in the target schema
• Slot derivation names should be valid slots on their parent class
• Missing required slot derivations could be flagged

Source schema validation:

• `populated_from` references should resolve to valid source classes/tables
• Source slot references in expressions should exist in the source schema

This would catch typos, references to removed/renamed schema elements, and spec/schema drift in both directions.

This is the natural next step after #190 — structural validation is necessary but not sufficient.

[github-actions]

Summary

This issue proposes a semantic validation layer on top of the structural validation added in PR #190 (closes #140). It represents the natural second phase of spec validation: structural → semantic.

Current state (after #190)

validate-spec / validate_spec() in src/linkml_map/validator.py validates transformation spec YAML against the transformer_model.yaml JSON Schema. It catches:

• Unknown keys, wrong field types, malformed nesting
• Structural problems (e.g. missing required top-level fields)

It does not cross-reference the spec against any source or target LinkML schemas.

Proposed additions

Target schema checks:

• Every class_derivations key (the target class name) should exist in the target schema's SchemaView
• Every slot_derivations key should be a valid slot on its parent class in the target schema
• Missing required slot derivations could be flagged as warnings

Source schema checks:

• Every populated_from value in a ClassDerivation should name a valid source class
• Every populated_from value in a SlotDerivation should be a valid slot in the source class
• Source slot references in expr strings could be checked (harder — requires parsing expressions)

Implementation notes

The infrastructure already exists: Transformer has source_schemaview and target_schemaview (both linkml_runtime.SchemaView). The new validation logic would need to:

1. Accept optional source/target schema paths alongside the spec
2. Load them via SchemaView
3. Walk class_derivations and slot_derivations, checking .all_classes() and .all_slots() / induced_slot()

The validate_spec() function signature would likely grow to accept source_schema and target_schema keyword arguments, keeping schema-less structural validation as the default.

Relationship to other open issues

• Support multi-source class derivations via sources, slot-level sources, and _source_class binding #193 (multi-source sources list): Once implemented, the sources list entries on ClassDerivation and SlotDerivation would also need to be validated against source schemas — this issue should track that.
• Add filter_rows expression to ClassDerivation for row-level filtering #187 (filter_rows), Implement multi-row aggregation, group-by, and collection membership (in) operator #188 (group-by aggregation): Expression-level slot references in those features would benefit from the source-slot existence checks proposed here.
• Convert source_schema and target_schema slot values into complex objects #161 (source/target schema as complex objects): Aligns with making schema references first-class in the spec.

Error types to catch

Error	Example
Unknown target class	class_derivations: PersonTypo:
Unknown target slot	slot_derivations: naem: (typo for name)
Invalid source class in populated_from	populated_from: NonExistentTable
Invalid source slot in populated_from	populated_from: phv_typo_123
Schema drift	A slot renamed in source/target schema but not updated in spec

This would catch a large category of "silent failure" bugs where the transformer runs without error but produces empty or wrong output because a slot reference resolves to None.