[data-shapes] SHACL UI Task Force Scope (#523)

edmondchuc has just created a new issue for https://github.com/w3c/data-shapes:

== SHACL UI Task Force Scope ==
> [!NOTE]
> This issue outlines the scope of the UI Task Force and the topics up for consideration. You can find further discussions on each topic in the child issues.

---
### Support for a List of Common and Advanced Patterns
In SHACL, there are sometimes multiple ways to achieve the same thing. In user-interface scenarios, it might be difficult for implementors to support every variation. A list of patterns might steer the user to follow the accepted patterns that are widely supported by user-interface engines.

The patterns also serve as a quick reference guide for end-users.

Discussion:
- What qualifies as common vs advanced?
- Are patterns normative or informative?
- Should this be in the spec document or as a separate note with a life of its own?

Prior art:
* [Form Generation using SHACL and DASH](https://datashapes.org/forms.html)

### Support for Core Constraint Components
SHACL UI should add support for core constraint components given that they are widely used and well supported by existing validation processors.

Add support for core constraint components for SHACL user-interfaces.

Discussion:
- Are all core constraint components supported?
- Are all core constraint components required?
- What are some core constraint components that should be optional due to their UI complexity?
- How are they used in view versus edit mode?

Links:
- [SHACL 1.2 Core - Core Constraint Components](https://www.w3.org/TR/shacl12-core/#core-components)

### Support for SHACL Property Paths
Add support by clarifying when a property path is applicable in viewing and editing scenarios.

Consider scenarios where property paths can be used for querying and how they are applied to user-interface use cases.

DASH Forms provide a couple of examples on how to render forms using property paths, including turning nested forms into a flattened form as a view.

Discussion:
- Which property paths are applicable to which scenarios?
- How are property paths rendered in forms?
- How are property paths used for querying?

Links:
- [SHACL 1.2 Core - SHACL Property Paths](https://www.w3.org/TR/shacl12-core/#property-paths)
- [Form Generation using SHACL and DASH - Path Expressions](https://datashapes.org/forms.html#paths)

### Support for SHACL Node Expressions
Add support for node expressions, a feature that allows dynamic calculations and selections within the user interface.

Node expressions can be used to:
- Calculate values within forms
- Select user-interface widgets
- Selection mechanism for other user-interfaces beyond forms

Discussion:
- How does it work within a form?
- How is it used to select widgets?
- Where else can node expressions be used for user-interfaces?

Links:
- [SHACL 1.2 Core - Node Expressions](https://www.w3.org/TR/shacl12-core/#node-expressions)

### Support for RDF 1.2 Features
RDF 1.2 adds reification as a way to annotate triples. This allows statements to be made about other statements.

Add support for RDF reification, including reification-related constraint components, for both viewing and editing. Reification may also be used in provenance tracking for editing applications and support actions such as roll-back or history viewing.

RDF 1.2 also defines initial text direction for RDF literals. Add support for handling such literals for both display, editing and storage.

Discussion:
- How does reification work in both viewing and editing?
- How does SHACL Core affect the display of reified triples?

Links:
- [RDF 1.2 Concepts and Abstract Syntax - Triple Terms and Reification](https://www.w3.org/TR/rdf12-concepts/#section-triple-terms-reification)
- [SHACL 1.2 Core - sh:reifierShape, sh:reificationRequired](https://www.w3.org/TR/shacl12-core/#ReifierShapeShapeConstraintComponent)
- [RDF 1.2 Concepts and Abstract Syntax - Initial Text Direction](https://www.w3.org/TR/rdf12-concepts/#section-text-direction)

### Support for DASH Widgets
DASH defines form widgets for both viewing and editing. Both the data and the selected shape determine the available widgets and the default selected widget based on a scoring algorithm.

SHACL UI should support the same or a similar mechanism.

Discussion:
- What widgets should be included?
- What new widgets should be added?
- What widget selection techniques or algorithms should be considered? Node expressions?
- Should widgets outside of forms be considered?
 - Inline search widgets?
 - Widgets like accordions and tabs for property groups?
 - Listing and tree widgets for navigation?

Links:
- [Form Generation using SHACL and DASH - Dash Widgets](https://datashapes.org/forms.html)

### Support for DASH Property Role
DASH Property Roles provides a vocabulary to annotate the role of property shapes for different uses. These include labels, descriptions, icons, depiction (to display an image), system identifiers via IDRole, and secondary information via KeyInfoRole.

SHACL user-interface should support the same mechanism to define property roles already defined in DASH. New property roles may also be considered and the mechanism to define roles may be reused for shapes in general. For example, declaring node shapes that are the "root" shape for the SHACL targets.

Discussion:
- What property roles, both existing in DASH and new, should be considered?
- Should defining roles be applicable to shapes in general?

Links:
- [Dash Property Roles and Resource Summaries](https://datashapes.org/propertyroles.html)

### Support for Nested Node Shape Selection
Provide a mechanism to select a suitable node shape when multiple shapes match the node target.

Example: A user selects a value for their home country. Based on the selected country, a suitable shape matching the node value is used to display a nested address form. The nested address form may have different fields with different layout arrangement depending on the country.

Discussion:
- Clarify the example
- Does this use `sh:node`? Or maybe `sh:or`?
- More than one node shape may match. Should this prompt the user to select one? Or should there be a rule system to select the most suitable shape based on some criteria?

Links:
- [SHACL 1.2 Core - sh:node](https://www.w3.org/TR/shacl12-core/#NodeConstraintComponent)
- [SHACL 1.2 Core - sh:or](https://www.w3.org/TR/shacl12-core/#OrConstraintComponent)

### Support Vocabulary for Customising Layout
Add support for describing form layout, including composing together with SHACL property groups.

Discussion:
- What layout system should it be? Grid?

Links:
- [SHACL 1.2 Core - sh:group](https://www.w3.org/TR/shacl12-core/#group)

### Support Alerts and Messages
SHACL UI should support a way to display alerts and messages in the form. These messages can be both positive and negative and potentially sourced via the validation report and provide a vocabulary to customise icons, styling, and colour of the message.

Discussion:
- Clarify where these alerts and messages are displayed in the form
- Are they tied to the validation report directly?
- Can this be reused outside of form editing?

### Support using Shapes to Frame JSON-LD
Use SHACL shapes for JSON-LD framing. Either SHACL shapes are converted to a JSON-LD frame that is passed along with the RDF data to a JSON-LD processor as input to produce a custom tree-like structure for user-interface rendering, or if more advanced features are required, not supported by JSON-LD framing, a SHACL-specific framing approach is defined. This potentially has reuses in other JSON-related scenarios such as shaping GraphQL and OpenAPI responses.

Discussion:
- How is this used in user-interfaces?
- Does JSON-LD Framing support all required features?

Links:
- [JSON-LD 1.1 Framing](https://www.w3.org/TR/json-ld11-framing/)

### SPARQL Support in User-Interfaces
Should we consider SPARQL for user-interfaces at all? Do shapes provide enough querying capability to not need SPARQL?

Do we need a section on SPARQL Update to describe how edits are applied to forms?

Links:
- [SPARQL 1.2 Query Language](https://www.w3.org/TR/sparql12-query/)
- [SPARQL 1.2 Update](https://www.w3.org/TR/sparql12-update/)

### Support Enabling and Disabling of Shapes and Constraints
This is related to user-interfaces but might belong in SHACL Core instead. To maximise shape reuse, SHACL needs to provide a way to enable and disable both shapes and individual constraints.

Discussion:
- Confirm if this topic is needed as it appears SHACL 1.2 Core already supports this.

Links:
- [SHACL 1.2 Core - Deactivating Shapes and Constraints](https://www.w3.org/TR/shacl12-core/#deactivated)

### Support using SHACL Shapes for Searching, Querying and Filtering
Other than form rendering of data, SHACL should also support generating forms for searching, querying and filtering.

These search forms can be described using a combination of node shapes, property shapes and their constraints. For example, a simple facet filter can be described using a property shape with `sh:in` with the possible values. More complex facets with autocomplete can be composed together with a node shape, property shape and label role.

Discussion:
- Confirm the use case
- Can this be reused outside of user-interfaces?


Please view or discuss this issue at https://github.com/w3c/data-shapes/issues/523 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 22 August 2025 09:44:12 UTC