Demote annotated property group to "all fields" priority

mih commented

2025-04-23 15:28:39 +00:00

Owner

Everything is derived from Thing and this class has an annotated property group. This fact attributes a certain priority to those properties and makes them show without "all fields" being enabled.

Here this is undesirable.

More desirable would be to include pid in the respective property group of each class where it is relevant (and thereby live it up to the top, where is is better placed when required).

If that is done, the ThingPropertyGroup (or any identified one) should be demoted to only show, when "all fields" is enabled.

Everything is derived from `Thing` and this class has an annotated property group. This fact attributes a certain priority to those properties and makes them show without "all fields" being enabled. Here this is undesirable. More desirable would be to include `pid` in the respective property group of each class where it is relevant (and thereby live it up to the top, where is is better placed when required). If that is done, the `ThingPropertyGroup` (or any identified one) should be demoted to only show, when "all fields" is enabled.

mih referenced this issue

2025-04-23 15:28:57 +00:00

Property order not valid #12

jsheunis commented

2025-04-23 18:02:59 +00:00

Owner

For clarity

While the Thing class has sh:group: ThingPropertyGroup annotations, the relevant ThingPropertyGroup a sh:PropertyGroup declaration isn't provided anywhere and is consequently not part of the SHACL that is ingested into a shacl-vue deployment. That would be necessary for shacl-vue to handle between-group ordering and within-group property ordering in the intended way, and also to display group-level info such as titles and descriptions.

I disabled all ordering based on pre-specified sh:PropertyGroups and sh:group annotations when I introduced the reverse hierarchical ordering recently. I did this because there will inevitably be some conflicts between the two types if they co-exist, and I don't think it's important enough to deal with that type of conflict resolution right now. It might make sense for some future use case to allow selecting between the different types of groups/ordering via configuration, or to merge the approaches somehow, but I'll leave it for when there's a clear need.

This all means, the current sh:group: ThingPropertyGroup annotations on properties of the Thing class do nothing in shacl-vue. They aren't used to determine class inheritance (I get that from subclass statements in the OWL). However, they could be used as is, for whatever reason we think would be useful.

Getting back to the issue

Everything is derived from Thing and this class has an annotated property group. This fact attributes a certain priority to those properties and makes them show without "all fields" being enabled.

Actually, there are currently only two aspects that determine (rightly or wrongly) whether a field is shown by default:

if it is a required field
if it has an sh:name specified (this comes either from linkml slot title or a linkml slot annotation sh:name)

All other fields will only show when the "All fields" switch is true.

So what is desirable?

My feeling is that we should have a set of default rules for a grouping/ordering approach that is independent of sh:group annotations (with or without specified sh:PropertyGroups):

use, by default, the reverse hierarchical class ordering that we introduced recently
for all classes, show by default only properties that are required: true or have some sort of recommended:true annotation
within each class:
- show required fields first
- order the rest of the properties by sh:order annotation
- if some properties do not have an sh:order annotation, order randomly or alphabetically, or some other spec

This means we would not implicitly give some priority to any property with a sh:group or sh:name annotation.

An argument could also be made for removing all required properties from their respective originating classes and adding them to a seperate required "group" on top.

What do you think?

### For clarity While the `Thing` class has [`sh:group: ThingPropertyGroup` annotations]([url](https://github.com/psychoinformatics-de/datalad-concepts/blob/main/src/things/v1.yaml#L406-L461)), the relevant `ThingPropertyGroup a sh:PropertyGroup` declaration isn't provided anywhere and is consequently not part of the SHACL that is ingested into a `shacl-vue` deployment. That would be necessary for `shacl-vue` to handle between-group ordering and within-group property ordering in the intended way, and also to display group-level info such as titles and descriptions. I disabled all ordering based on pre-specified `sh:PropertyGroup`s and `sh:group` annotations when I introduced the reverse hierarchical ordering recently. I did this because there will inevitably be some conflicts between the two types if they co-exist, and I don't think it's important enough to deal with that type of conflict resolution right now. It might make sense for some future use case to allow selecting between the different types of groups/ordering via configuration, or to merge the approaches somehow, but I'll leave it for when there's a clear need. This all means, the current `sh:group: ThingPropertyGroup` annotations on properties of the `Thing` class do nothing in `shacl-vue`. They aren't used to determine class inheritance (I get that from subclass statements in the OWL). However, they could be used as is, for whatever reason we think would be useful. ### Getting back to the issue > Everything is derived from Thing and this class has an annotated property group. This fact attributes a certain priority to those properties and makes them show without "all fields" being enabled. Actually, there are currently only two aspects that determine (rightly or wrongly) whether a field is shown by default: - if it is a required field - if it has an `sh:name` specified (this comes either from linkml slot `title` or a linkml slot annotation `sh:name`) All other fields will only show when the "All fields" switch is true. ### So what is desirable? My feeling is that we should have a set of default rules for a grouping/ordering approach that is independent of `sh:group` annotations (with or without specified `sh:PropertyGroups`): - use, by default, the reverse hierarchical class ordering that we introduced recently - for all classes, show by default only properties that are `required: true` or have some sort of `recommended:true` annotation - within each class: - show required fields first - order the rest of the properties by `sh:order` annotation - if some properties do not have an `sh:order` annotation, order randomly or alphabetically, or some other spec This means we would not implicitly give some priority to any property with a `sh:group` or `sh:name` annotation. An argument could also be made for removing all required properties from their respective originating classes and adding them to a seperate required "group" on top. What do you think?

jsheunis commented

2025-04-24 12:49:04 +00:00

Owner

Some exchanges after the above:

@mih

I would prefer simple. To solve the order problem, if we can limit ourselves to just looking at sh:order, this would be my preference
For anything that does not have an sh:order, use the reverse class sectioning. I agree with avoiding any interactions re priorities with sh:name or sh:group
Q: if a slot prop in class A has sh:order 5, and I derive a class B from it, and annotate in B the slot with sh:order 4. Is the effective order then 4 in B? IOW can I reorder?

@jsheunis

Yes, that is an important point. One can reorder. And if reordering is not done explicitly, the order (as with any other annotations) is inherited and it can screw up ordering in your derived class

@mih

... which slots to show at all (without "all fields" enabled) - I agree that making this explicit makes sense. We can invent an annotation for that. It would be important to have it be a boolean to be able to turn a recommendation of a base class off in a derived class

@jsheunis

also, should we extract required properties into their own top-level display group, or will we just give them priority via sh:order

@mih

I think this is not needed. Just sh:order.
I believe in practice for any tuned class, we would have slots from all of the hierarchy in the "recommended" set, and that set should go on top, and it should be ordered by sh:order
for the rest: reverse class hierarchy and alphabetical by sh:name or title, whatever is being effectively displayed
some of this is hard to predict how it would feel like
but we are going through significant examples right now, we will know soon

@jsheunis

yes, e.g. we could also have slot_usage for pid in the top-level class. Currently it is displaying in the group for Thing.

@mih

yes, I think this would be sensible.

Some exchanges after the above: @mih > I would prefer simple. To solve the order problem, if we can limit ourselves to just looking at `sh:order`, this would be my preference > For anything that does not have an sh:order, use the reverse class sectioning. I agree with avoiding any interactions re priorities with `sh:name` or `sh:group` > Q: if a slot prop in class A has sh:order 5, and I derive a class B from it, and annotate in B the slot with sh:order 4. Is the effective order then 4 in B? IOW can I reorder? @jsheunis > Yes, that is an important point. One can reorder. And if reordering is not done explicitly, the order (as with any other annotations) is inherited and it can screw up ordering in your derived class @mih > ... which slots to show at all (without "all fields" enabled) - I agree that making this explicit makes sense. We can invent an annotation for that. It would be important to have it be a boolean to be able to turn a recommendation of a base class off in a derived class @jsheunis > also, should we extract required properties into their own top-level display group, or will we just give them priority via sh:order @mih > I think this is not needed. Just `sh:order`. > I believe in practice for any tuned class, we would have slots from all of the hierarchy in the "recommended" set, and that set should go on top, and it should be ordered by sh:order > for the rest: reverse class hierarchy and alphabetical by sh:name or title, whatever is being effectively displayed > some of this is hard to predict how it would feel like > but we are going through significant examples right now, we will know soon @jsheunis > yes, e.g. we could also have slot_usage for pid in the top-level class. Currently it is displaying in the group for Thing. @mih > yes, I think this would be sensible.

jsheunis commented

2025-04-25 09:14:39 +00:00

Owner

Ok I now have the broad ordering and show/hide feature in place with the following rules:

Group all properties by their originating class, and display these class groups in reverse hierarchical order. e.g.:
- Person
- Thing
- ThingMixin
Show the top-level class group, here Person, by default
Show all properties of the top-level group by default, ordered by the sh:order annotation of the property (relative to other properties in the group)
Hide all other class groups (here Thing and ThingMixin) and their properties by default, unless:
- the property is required
- the property is recommended (in LinkML, the slot has an annotation: dlco:recommended: true, with the prefix dlco: https://concepts.datalad.org/ )
For all non-top-level class groups, also order their displayed properties by the sh:order annotation of the property (relative to other properties in the group)

Notes:

sh:group and sh:PropertyGroup annotations do not play any role in the above process.
we could also replace dlco with whichever improved prefix we can conjure up
it is important to re-annotate properties from inherited classes for when these properties' annotations are not relevant anymore in their new context. For example the CurationAid has sh:order annotations for display_name and curation_comments (and none for identifiers) and these slots are all inherited into Person where they keep their original annotation. This is why will appear in the ordered properties in a location where they might not have explicitly been placed according to the LinkML slot_usage of the Person class.

Demo video:

Ok I now have the broad ordering and show/hide feature in place with the following rules: 1. Group all properties by their originating class, and display these class groups in reverse hierarchical order. e.g.: - `Person` - `Thing` - `ThingMixin` 2. Show the top-level class group, here `Person`, by default 3. Show all properties of the top-level group by default, ordered by the `sh:order` annotation of the property (relative to other properties in the group) 4. Hide all other class groups (here `Thing` and `ThingMixin`) and their properties by default, unless: - the property is required - the property is recommended (in LinkML, the slot has an annotation: `dlco:recommended: true`, with the prefix `dlco: https://concepts.datalad.org/` ) 5. For all non-top-level class groups, also order their displayed properties by the `sh:order` annotation of the property (relative to other properties in the group) Notes: - `sh:group` and `sh:PropertyGroup` annotations do not play any role in the above process. - we could also replace `dlco` with whichever improved prefix we can conjure up - it is important to re-annotate properties from inherited classes for when these properties' annotations are not relevant anymore in their new context. For example the [`CurationAid`]([url](https://hub.psychoinformatics.de/inm7/inm7-concepts/src/commit/def7bd33f238bed630d0864f4eb2055caf4aa3fe/src/simpleinput/unreleased.yaml#L348-L369)) has `sh:order` annotations for `display_name` and `curation_comments` (and none for identifiers) and these slots are all inherited into `Person` where they keep their original annotation. This is why will appear in the ordered properties in a location where they might not have explicitly been placed according to the LinkML `slot_usage` of the `Person` class. Demo video: <video src="/attachments/8ccf2605-0132-48a0-81e5-6c065cb75a26" title="shacl-vue-order.mp4" controls></video>

shacl-vue-order.mp4

2.9 MiB

mih commented

2025-04-25 09:19:53 +00:00

Author

Owner

Works for me! Thanks