[UI] Could `sh:order` and / or `sh:group` be moved to the `shui` namespace?

[danielbeeke]

In the SHACL 1.0 spec we have the chapter "2.3.2 Non-Validating Property Shape Characteristics" which contains sh:order and sh:group. I wonder if it would make sense to move these two to the shui namespace and deprecate them. Meanwhile we should recommend or require implementers of a spec compliant SHACL renderer to still support sh:order and sh:group. However going forward shui:order and shui:group would be the standard way to go.

Pro's

• UI concerns are in the UI namespace
• Core spec is cleaned up from these UI properties

Cons

• We need to think of who used these predicates and how they have been used.

• Are there uses of sh:order and sh:group besides UI work?

• Are they both used only in UI or is sh:group easier to move?

[HolgerKnublauch]

I guess this would also require moving sh:PropertyGroup.

Overall my impression is that such changes are too hard and that the ship has sailed once a property is in heavy use. If we could restart, then likely these would be in shui, but we do have existing ontologies to look after and should aim at backwards compatibility with SHACL 1.0.

Another concern is where to stop - in a sense we could then also move sh:name and sh:description which have no semantic value.

(sh:order is used in SHACL-AF but that shouldn't be a show stopper).

[afs]

When it's just a few properties are used, having split namespaces can be inconvenient (c.f. rdf: and rdfs:).

One possibility is to define synonyms, a property that is accepted instead of another.
e.g. shui:order would have a synonym sh:order when used in the property position.

This is not inference, it is syntactic convenience - there is only one triple so sh:maxCount is preserved. It is more a "parse time macro" - the processor would treat sh:order as shui:order.