Fix incorrect use of value slots in extra_slots examples.

[gouttegd]

The examples provided in the meta-schema for the extra_slots slot incorrectly use the value slot of the Example class, as in:

extra_slots:
  examples:
    - value:
        allowed: true

This is incorrect because the value slot is string-typed: it cannot contain an object such as {allowed: true}.

This is bad because (1) it is not a good sign that LinkML's own meta-schema is invalid according to its own rules, and (2) this prevents the schema from being loaded when using an implementation that actually cares about typing issues.

The Example class defines another slot, value_object (aliased to simply object), that is specifically intended to represent values that are not simple strings. This commit updates the examples on the extra_slots definition to use object rather than value.

closes linkml/linkml#3245

[gouttegd]

This PR requires that issue 3246 in linkml-runtime be fixed (PR here).

[sneakers-the-rat]

Whoopsie daisy, my bad

[sneakers-the-rat]

It does seem like we should be running the validator on the metamodel in CI to avoid this in the future

[gouttegd]

It does seem like we should be running the validator on the metamodel in CI to avoid this in the future

That’s already the case: the “main” CI workflow does call make test, and make test does (among other things) run the linkml-normalize validator.

But linkml-normalize does not catch this kind of error. And in fact and to make things worse, if you fix the errors here, then linkml-normalize will complain because it does not recognise linkml:Any-typed slots (at least it did not recognise them; the issue has been fixed in linkml-runtime, but that fix has yet to find a way into a release).

So, to fix things here and now, two solutions:

A. Wait until a new version of linkml-runtime has been published, and then make sure the CI workflow is using the latest version. Then this PR can be merged, no other changes required.

B. Amend the Makefile to replace the use of linkml-normalize by linkml validate.

I am inclined to think that B should be the way to go, as linkml validate seems more reliable than linkml-normalize. Not only it is already aware of linkml:Any, it also does catch the the very kind of error that caused linkml/linkml#3245, contrary to linkml-normalize. Which means that switching to linkml-normalize would also allow to prevent this kind of error from occurring again.

But I leave the decision to the LinkML devs.