Split from #1083. See the use case issue on varying field order and visibility per deployment.
Question
Should SHACL UI define a way for a deployment to override UI choices from shapes it does not control, covering at least field order and whether a property is displayed?
Use cases
Two parts
Ordering override. A deployment states an order differing from the shapes, without editing them. Sketch from the meeting:
<#myOverrideShape>
a sh:OverrideShape ;
sh:target ex:CompanyShapeName ;
sh:order 3 .
Hiding. A deployment states that a property is not displayed while remaining subject to validation. sh:deactivated does not express this: deactivating a property shape also removes its constraints from validation, so "hidden but still validated" is currently inexpressible. A term such as shui:hidden would fill the gap.
Why this matters for the other decisions
This bears directly on the sh:order decision. The main argument against defined ordering is that deployments legitimately need different orders. An override mechanism means the base order can be defined while the variation is expressed explicitly, in a form that moves with the shapes rather than living in one product's configuration.
Proposed resolution
Two separate pieces of work, in this order.
1. Define a hiding property, for example shui:hidden. A boolean on a property shape meaning the property is not displayed while remaining subject to validation. This is useful on its own, independently of any override mechanism, to authors who do own their shapes. sh:deactivated cannot express it, because deactivating a property shape also removes its constraints from validation. This piece looks small and self contained, and I would like it agreed on its own rather than waiting for the second piece.
2. Define a way to state UI properties for a shape from outside it. An override construct that names what it applies to and carries one or more UI properties, so a deployment can adjust presentation without editing shapes it does not own. Once shui:hidden exists, the same construct should be able to carry it.
On the form this takes, the sketch discussed in the meeting was:
<#myOverrideShape>
a sh:OverrideShape ;
sh:target ex:CompanyShapeName ;
sh:order 3 .
I do not think targeting works quite like this, and I would like input on it. sh:order applies to a property shape rather than a node shape, so the override has to identify a specific property shape. Published application profiles very often express property shapes as blank nodes, which have no IRI to target. If the mechanism can only target property shapes with IRIs, it will not work for the profiles that motivate it.
An alternative that avoids the problem is to target the node shape and the path together:
<#myOverride>
a shui:Override ;
shui:onShape ex:CompanyShape ;
shui:onPath ex:legalName ;
sh:order 3 ;
shui:hidden true .
This addresses a property by where it sits rather than by identity, so blank node property shapes are reachable.
I have written shui:Override rather than OverrideShape here, but I do not hold a strong view. The argument for dropping "Shape" is that in SHACL a shape constrains a focus node, and an override does not: it carries presentation properties and points at a shape elsewhere, so calling it a shape may suggest a validator should do something with it. The argument for keeping it is that it reads naturally and stays close to familiar naming. Happy to go with whichever the task force prefers.
UI only, or generalised into Core? This is the question I would most like a view on, because the rest of the design follows from it.
UI scoped. The override carries UI properties only: ordering, hiding, and whatever else we define. It lives in shui:, it does not affect validation, and it is ours to specify.
Generalised. The same construct becomes a general way to state any property about a shape from outside it, including constraints. A deployment could then tighten sh:minCount on a profile it does not own, which is the same problem as ours but wider. That is a genuinely useful primitive, and it may be a better home for the idea.
The generalised version is a much larger design question. It affects validation, so it needs semantics we do not need for the UI case: what happens when an override contradicts a constraint it applies to, how overrides interact with sh:deactivated, and how they behave through sh:node. It would also need Core's agreement and fit into Core's timeline rather than ours.
My suggestion is to specify the UI scoped version now, in shui:, while keeping the design a clean subset of what a general mechanism would look like, so that nothing here would have to be undone if Core later generalises it. But I would rather we decide this deliberately than end up with the UI version by default. If the task force thinks the general version is the right home, it is worth raising with Core early, because that changes what we can realistically finish.
One thing worth checking before we design targeting from scratch: whether Core already has an idiom for attaching statements to a shape from outside it that we could reuse rather than invent.
Open questions
- How an override addresses a property shape, given that blank node property shapes are common in published profiles
- Whether this is UI scoped in
shui: or a general mechanism to raise with Core
- How overrides compose when more than one applies to the same property
- Whether an override can carry any UI property or only a defined subset
- Naming:
shui:Override, shui:OverrideShape, or something else
Split from #1083. See the use case issue on varying field order and visibility per deployment.
Question
Should SHACL UI define a way for a deployment to override UI choices from shapes it does not control, covering at least field order and whether a property is displayed?
Use cases
Two parts
Ordering override. A deployment states an order differing from the shapes, without editing them. Sketch from the meeting:
Hiding. A deployment states that a property is not displayed while remaining subject to validation.
sh:deactivateddoes not express this: deactivating a property shape also removes its constraints from validation, so "hidden but still validated" is currently inexpressible. A term such asshui:hiddenwould fill the gap.Why this matters for the other decisions
This bears directly on the
sh:orderdecision. The main argument against defined ordering is that deployments legitimately need different orders. An override mechanism means the base order can be defined while the variation is expressed explicitly, in a form that moves with the shapes rather than living in one product's configuration.Proposed resolution
Two separate pieces of work, in this order.
1. Define a hiding property, for example
shui:hidden. A boolean on a property shape meaning the property is not displayed while remaining subject to validation. This is useful on its own, independently of any override mechanism, to authors who do own their shapes.sh:deactivatedcannot express it, because deactivating a property shape also removes its constraints from validation. This piece looks small and self contained, and I would like it agreed on its own rather than waiting for the second piece.2. Define a way to state UI properties for a shape from outside it. An override construct that names what it applies to and carries one or more UI properties, so a deployment can adjust presentation without editing shapes it does not own. Once
shui:hiddenexists, the same construct should be able to carry it.On the form this takes, the sketch discussed in the meeting was:
I do not think targeting works quite like this, and I would like input on it.
sh:orderapplies to a property shape rather than a node shape, so the override has to identify a specific property shape. Published application profiles very often express property shapes as blank nodes, which have no IRI to target. If the mechanism can only target property shapes with IRIs, it will not work for the profiles that motivate it.An alternative that avoids the problem is to target the node shape and the path together:
This addresses a property by where it sits rather than by identity, so blank node property shapes are reachable.
I have written
shui:Overriderather thanOverrideShapehere, but I do not hold a strong view. The argument for dropping "Shape" is that in SHACL a shape constrains a focus node, and an override does not: it carries presentation properties and points at a shape elsewhere, so calling it a shape may suggest a validator should do something with it. The argument for keeping it is that it reads naturally and stays close to familiar naming. Happy to go with whichever the task force prefers.UI only, or generalised into Core? This is the question I would most like a view on, because the rest of the design follows from it.
UI scoped. The override carries UI properties only: ordering, hiding, and whatever else we define. It lives in
shui:, it does not affect validation, and it is ours to specify.Generalised. The same construct becomes a general way to state any property about a shape from outside it, including constraints. A deployment could then tighten
sh:minCounton a profile it does not own, which is the same problem as ours but wider. That is a genuinely useful primitive, and it may be a better home for the idea.The generalised version is a much larger design question. It affects validation, so it needs semantics we do not need for the UI case: what happens when an override contradicts a constraint it applies to, how overrides interact with
sh:deactivated, and how they behave throughsh:node. It would also need Core's agreement and fit into Core's timeline rather than ours.My suggestion is to specify the UI scoped version now, in
shui:, while keeping the design a clean subset of what a general mechanism would look like, so that nothing here would have to be undone if Core later generalises it. But I would rather we decide this deliberately than end up with the UI version by default. If the task force thinks the general version is the right home, it is worth raising with Core early, because that changes what we can realistically finish.One thing worth checking before we design targeting from scratch: whether Core already has an idiom for attaching statements to a shape from outside it that we could reuse rather than invent.
Open questions
shui:or a general mechanism to raise with Coreshui:Override,shui:OverrideShape, or something else