Family name etc not in "Properties from User" #18

New issue

Closed

opened 2025-05-15 13:12:39 +00:00 by jsheunis · 1 comment

jsheunis commented

2025-05-15 13:12:39 +00:00

Owner

This is an ongoing struggle...

In https://github.com/psychoinformatics-de/shacl-vue/pull/104, the latest property grouping approach was introduced:

A property should be divided into the class group that either made the latest change to it if it was inherited, or into the class that introduced the property.

It seems like this approach did not foresee the situation that we have currently, where both Person and its inheriting class User have properties like family_name annotated with the exact same sh:order (or any other key/value for that matter). So what happens is that when a form for User is opened, the latest grouping approach will place it in the "Properties from Person" group, which we don't want.

This stems from the same issue that was discussed in the above mentioned PR, which is that there is no machine-actionable knowledge about annotation inheritance in the shacl that is exported from a linkml schema. IOW, if the Person node shape has sh:order: 1 for a given property, and the User node shape also has sh:order: 1 for that same property, we assume that this property shape has been inherited because that is the default behaviour. There is no way of knowing from an exactly matched property shape that the User class was in fact also annotated with the same key/value pairs. That is unless the annotations changed, in which case the property shapes change.

A patchy solution would be to add another annotation to that same property in the inheriting class, such that it forces a change to be recognised in the exported shacl. Alternatively the order value could be changed. It can be a decimal value too.

I will try to think of other ways to deal with this in the code rather than annotation, but I doubt that I will come up with a sound alternative.

This is an ongoing struggle... In https://github.com/psychoinformatics-de/shacl-vue/pull/104, the latest property grouping approach was introduced: > A property should be divided into the class group that either made the latest change to it if it was inherited, or into the class that introduced the property. It seems like this approach did not foresee the situation that we have currently, where both `Person` and its inheriting class `User` have properties like `family_name` annotated with the exact same `sh:order` (or any other key/value for that matter). So what happens is that when a form for `User` is opened, the latest grouping approach will place it in the "Properties from Person" group, which we don't want. This stems from the same issue that was discussed in the above mentioned PR, which is that there is no machine-actionable knowledge about annotation inheritance in the shacl that is exported from a linkml schema. IOW, if the `Person` node shape has `sh:order: 1` for a given property, and the `User` node shape also has `sh:order: 1` for that same property, we assume that this property shape has been inherited because that is the default behaviour. There is no way of knowing from an exactly matched property shape that the `User` class was in fact also annotated with the same key/value pairs. That is unless the annotations changed, in which case the property shapes change. A patchy solution would be to add another annotation to that same property in the inheriting class, such that it forces a change to be recognised in the exported shacl. Alternatively the order value could be changed. It can be a decimal value too. I will try to think of other ways to deal with this in the code rather than annotation, but I doubt that I will come up with a sound alternative.