Bring shacl annotations closer to root classes in `datalad-concepts` #11

New issue

Open

opened 2024-12-13 08:58:37 +00:00 by jsheunis · 1 comment

jsheunis commented

2024-12-13 08:58:37 +00:00

(Migrated from hub.datalad.org)

Original issue: https://github.com/psychoinformatics-de/shacl-vue/issues/24

"Moved" here since this involves the integration between dlco and shacl-vue, and since the code for generating SHACL from UI-annotated schemas is now in this repo.

The first order of business is to start annotating Thing and other recently updated base classes, run the pipeline to generate annotated shacl schemas, and then see how the forms look.

Original issue: https://github.com/psychoinformatics-de/shacl-vue/issues/24 "Moved" here since this involves the integration between `dlco` and `shacl-vue`, and since the code for generating SHACL from UI-annotated schemas is now in this repo. The first order of business is to start annotating `Thing` and other recently updated base classes, run the pipeline to generate annotated shacl schemas, and then see how the forms look.

jsheunis commented

2024-12-17 09:44:53 +00:00

(Migrated from hub.datalad.org)

Update: ui annotations work fine on base classes.

The challenge is dealing sensibly with inheritance and the context within which the annotations of arbitrary classes/mixins will be used. This is not generally an issue for annotations like title or annotations that influence component rendering type, but more so for annotations that specify which group of slots a particular slot should belong to, and in which order a slot should appear in said group. If annotations should be self-contained per class/mixin, then one would e.g. say for ThingMixin that type should have sh:order: 0 and schema_type should have sh:order: 1, while on Thing class itself one could say that id should have sh:order: 0. However, there will be a clash of positions because the ThingMixin slots inherit their annotations into whichever context they are mixed into (or subclassed into for classes). So the question is then in which context annotations should be overwritten.

Some background

A sh:PropertyShape (derived from a slot) can have a sh:order (via slot annotation), which will be interpreted within the context of the sh:PropertyGroup (defined globally) that the particular slot is assigned to using sh:group (via slot annotation). The sh:order and sh:group will be inherited into new contexts when subclassing/mixing, unless the subclass overwrites these annotations using slot_usage. Additionally, sh:PropertyGroup can also have sh:order to e.g. define in which order the groups should appear in their parent context, e.g. the order of groups of slots in a form.

This means there is no problem whenever groups are unique to classes. Concretely, the ThingMixin can have ThingMixinGroup and nothing else has that, and all is good. Importantly: each leaf class that is a Thing (which also has ThingMixin) will also have the ThingMixinGroup. So if users don't want that to be displayed in their form rendering, they will need to overwrite these annotations on their leaf class slots.

**Update**: ui annotations work fine on base classes. The challenge is dealing sensibly with inheritance and the context within which the annotations of arbitrary classes/mixins will be used. This is not generally an issue for annotations like `title` or annotations that influence component rendering type, but more so for annotations that specify which group of slots a particular slot should belong to, and in which order a slot should appear in said group. If annotations should be self-contained per class/mixin, then one would e.g. say for `ThingMixin` that `type` should have `sh:order: 0` and `schema_type` should have `sh:order: 1`, while on `Thing` class itself one could say that `id` should have `sh:order: 0`. However, there will be a clash of positions because the `ThingMixin` slots inherit their annotations into whichever context they are mixed into (or subclassed into for classes). So the question is then in which context annotations should be overwritten. **Some background** A `sh:PropertyShape` (derived from a slot) can have a `sh:order` (via slot annotation), which will be interpreted within the context of the `sh:PropertyGroup` (defined globally) that the particular slot is assigned to using `sh:group` (via slot annotation). The `sh:order` and `sh:group` will be inherited into new contexts when subclassing/mixing, unless the subclass overwrites these annotations using `slot_usage`. Additionally, `sh:PropertyGroup` can also have `sh:order` to e.g. define in which order the groups should appear in their parent context, e.g. the order of groups of slots in a form. This means there is no problem whenever groups are unique to classes. Concretely, the `ThingMixin` can have `ThingMixinGroup` and nothing else has that, and all is good. Importantly: each leaf class that is a `Thing` (which also has `ThingMixin`) will also have the `ThingMixinGroup`. So if users don't want that to be displayed in their form rendering, they will need to overwrite these annotations on their leaf class slots.