SHACL 1.2 User Interfaces

Introduction

Content.

Scope

Content.

Terminology

Terminology used throughout this specification is taken from several sources:

SHACL 1.2 Core specification: technical terms for SHACL and RDF, the latter from [[rdf12-concepts]]

The SHACL & RDF terms include: binding , blank node , conformance , constraint , constraint component , data graph , datatype , failure , focus node , RDF graph , ill-formed , IRI , literal , local name , member , node , node shape , object , parameter , pre-binding , predicate , property path , property shape , RDF term , SHACL instance , SHACL list , SHACL subclass , shape , shapes graph , solution , subject , target , triple , validation , validation report , validation result , validator , value , value node .

Language Resolution

Language Resolution is the process of determining and ordering the values associated with a given subject-predicate pair, prioritizing the preferred or most relevant language value for display.

Label Resolution

Label Resolution is the process of selecting the most appropriate display label for an RDF resource, or generating a fallback value when no suitable value exists. It applies to both value nodes and properties identified by sh:path, the latter of which is commonly used to label form elements. The process includes language resolution and considers labeling-related annotations from the shapes graph, data graph, application environment, and user preferences, to determine the best label for UI presentation.

Property UI Component

A Property UI Component is a combination of constraints across multiple property shapes that share the same property path, focus node, and value nodes. It represents a single field (e.g., a text input, a dropdown) in a form.

Node UI Component

A Node UI Component is generated from a single focus node, typically containing one or more property UI components. It is often derived from one or more node shapes that apply to the focus node.

SHACL Renderer

A SHACL Renderer is software that processes SHACL shapes and data and dynamically generates a user-interface using one or more node UI components. Implementations may add supplementary UI elements, such as a submit button to save changes, controls to toggle between edit and view modes, selectors for focus node and node shape, or visualizations of validation report messages. They may also provide:

State management for editing, viewing, and tracking data changes
Widget management, including widget selection strategies
Logic for determining the initial focus node (target) and the best suited node shape
An interface to interact with the data layer

A SHACL Renderer operates on a data graph and a shapes graph, and may also take a focus node and a node shape. When all four inputs are provided, the renderer operates in manual mode. When the focus node or node shape is not provided, the renderer may operate in automatic mode, in which case the application determines appropriate values for the missing inputs.

Document Conventions

Within this specification, the following namespace prefix definitions are used:

Prefix	Namespace
`rdf:`	`http://www.w3.org/1999/02/22-rdf-syntax-ns#`
`rdfs:`	`http://www.w3.org/2000/01/rdf-schema#`
`sh:`	`http://www.w3.org/ns/shacl#`
`shui:`	`http://www.w3.org/ns/shacl-ui#`
`xsd:`	`http://www.w3.org/2001/XMLSchema#`
`ex:`	`http://example.com/ns#`
`dct:`	`http://purl.org/dc/terms/`

Within this specification, the following JSON-LD context is used:

{
  "@context": {
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "sh": "http://www.w3.org/ns/shacl#",
    "shui": "http://www.w3.org/ns/shacl-ui#",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "ex": "http://example.com/ns#",
    "dct": "http://purl.org/dc/terms/"
  }
}

Note that the URI of the graph defining the SHACL vocabulary itself is equivalent to the namespace above, i.e., it includes the #. References to the SHACL vocabulary, e.g., via owl:imports should include the #.

Throughout the specification, color-coded boxes containing RDF graphs in Turtle and JSON-LD will appear. The color and title of a box indicate whether it is a Shapes graph, a Data graph, or something else. The Turtle specification fragments use the prefix bindings given above. The JSON-LD specification fragments use the context given above. Only the Turtle specifications will have parts highlighted.

# This box represents an input shapes graph <s> <p> <o> .

// This box represents an input shapes graph

{
  "@id": "ex:s",
  "ex:p": {
    "@id": "ex:o"
  }
}

# This box represents an input data graph. # When highlighting is used in the examples: # Elements highlighted in blue are focus nodes ex:Bob a ex:Person . # Elements highlighted in red are focus nodes that fail validation ex:Alice a ex:Person .

// This box represents an input data graph

{
	"@graph": [
		{
			"@id": "ex:Alice",
			"@type": "ex:Person"
		},
		{
			"@id": "ex:Bob",
			"@type": "ex:Person"
		}
	]
}

# This box represents an output results graph

// This box represents an output results graph

Grey boxes such as this include syntax rules that apply to the shapes graph.

true denotes the RDF term "true"^^xsd:boolean. false denotes the RDF term "false"^^xsd:boolean.

TODO

RDF Abstract Model Compatibility

At the time of writing, RDF 1.2 is a Working Draft. This section will be reviewed and updated when RDF 1.2 becomes a W3C Recommendation.

SHACL Renderers implementing this specification MUST support RDF 1.1 and SHOULD support RDF 1.2. When RDF 1.2 is supported, and unless stated otherwise in this document, implementations SHOULD prefer RDF 1.2 syntax and data model features over their RDF 1.1 counterparts.

Property Paths

SHACL Property Paths can be used to render a SHACL shape as a user interface. Property paths define how data values are accessed or modified relative to a focus node.

The following subsections outline the scenarios in which SHACL UI implementations are expected to support different kinds of property paths for viewing and editing operations.

View Mode

In view mode, property paths are used to retrieve and display data values associated with a shape. A SHACL UI implementation must provide mechanisms to resolve these paths for visualization.

Predicate and Inverse Paths

SHACL UI implementations MUST support both predicate paths and inverse paths in view mode. This ensures that values reachable via simple forward or inverse relationships can be displayed to the user.

The following example illustrates how predicate and inverse paths are used in view mode to access and display values, either directly from the focus node or through incoming relationships from other nodes.

ex:PersonShape a sh:NodeShape ; sh:property [ sh:path foaf:name ; sh:name "Name" ; sh:datatype xsd:string ; ] ; sh:property [ sh:path [ sh:inversePath ex:member ] ; sh:name "Department" ; ] .

ex:alice a ex:Person ; foaf:name "Alice" . ex:researchDept a ex:Department ; ex:member ex:alice ; rdfs:label "Research Department" .

A SHACL UI could display the person’s foaf:name as text and list departments that reference the person via ex:member.

Complex Paths

SHACL UI implementations SHOULD support complex property paths in view mode. Complex paths include sequence paths, alternative paths, zero-or-more paths, one-or-more paths, and zero-or-one paths as defined in SHACL Core.

Support for complex paths is recommended, but can be left out in cases where the implementation aims to provide symmetry between view and edit modes, and complex paths are not supported in edit mode.

The following examples illustrate a sequence path and an alternative path, both of which may be used for richer data traversal in view mode.

ex:PersonShape a sh:NodeShape ; sh:property [ sh:path ( ex:address ex:cityName ) ; sh:name "City" ; sh:datatype xsd:string ; ] . ex:BookShape a sh:NodeShape ; sh:property [ sh:path [ sh:alternativePath ( dct:title rdfs:label ) ] ; sh:name "Title" ; sh:datatype xsd:string ; ] .

ex:alice a ex:Person ; ex:address ex:aliceAddress . ex:aliceAddress ex:cityName "Ghent" . ex:book1 a ex:Book ; dct:title "Linked Data Design" .

A SHACL UI could display Alice’s city as "Ghent" by traversing the ex:address node, and display the title of ex:book1 as “Linked Data Design”.

Edit Mode

In edit mode, property paths determine how changes to data and the creation of new data are applied through the user interface.

Predicate and Inverse Paths

SHACL UI implementations MUST support predicate paths and inverse paths in edit mode. This allows users to modify data linked by simple properties or inverse properties.

The following example illustrates how predicate and inverse paths can be used in edit mode to modify a person’s name and manage their membership in departments.

ex:PersonShape a sh:NodeShape ; sh:property [ sh:path foaf:name ; sh:name "Name" ; sh:datatype xsd:string ; ] ; sh:property [ sh:path [ sh:inversePath ex:member ] ; sh:name "Department" ; sh:class ex:Department ; ] .

ex:bob a ex:Person ; foaf:name "Bob" . ex:engDept a ex:Department ; ex:member ex:bob ; rdfs:label "Engineering Department" .

A SHACL UI might render a text input for foaf:name and a selector for the departments. Editing inverse paths requires the UI to ensure consistent updates on the related nodes.

Alternative Paths

SHACL UI implementations SHOULD support alternative paths in edit mode. This enables editing where a shape can constrain multiple potential properties, and the UI can allow users to choose which alternative to use when entering or modifying data.

When editing existing or newly created statements, the UI SHOULD provide a mechanism to update the predicate to one of the enumerated paths in the sh:alternativePath list, but only if those paths are either predicate paths or inverse paths. This restriction is necessary because the object of sh:alternativePath is a SHACL list that may contain any valid property path expression, including complex path types that are not generally feasible to edit directly through a user interface.

Although redundant, SHACL permits nesting of sh:alternativePath expressions. Such nesting simply flattens to a single list of predicate or inverse paths and does not alter the effective set of alternatives available for editing.

The following example illustrates how an alternative path can be used in edit mode to allow a book's title to be provided through either dct:title or rdfs:label.

Other Complex Paths

SHACL UI implementations MAY support the other complex paths (i.e., sequence paths, zero-or-more paths, one-or-more paths, and zero-or-one paths) in edit mode.

Implementers are encouraged to support these when their use cases require advanced data navigation or editing patterns, but such support is not mandatory as the complexity of editing through these paths may not be feasible in all user interface contexts.

Supporting complex property paths in edit mode introduces challenges related to ambiguity and the generation of intermediate data structures. Even when a path is used for view-only purposes, implementations must ensure that restrictions are in place to prevent ambiguous traversal results. SHACL property paths allow navigation across multiple steps in a graph, which can lead to situations where a single value is reachable through multiple distinct paths.

The following shape and data graph illustrate how a node can be reachable via a complex path expression, making editing operations ambiguous.

ex:CompoundThingShape a sh:NodeShape ; sh:property [ sh:path [ sh:zeroOrMorePath ex:hasPart ] ; sh:name "All Descendant Parts" ; sh:description "Traverses all parts and sub-parts using a zero-or-more path of hasPart relationships." ; ] .

ex:compounded-thing ex:hasPart ex:part-a ; ex:hasPart ex:part-b . ex:part-a ex:hasPart ex:screw . ex:part-b ex:hasPart ex:screw .

In this example, the node ex:screw can be reached from ex:compounded-thing through two distinct paths:

ex:compounded-thing → ex:hasPart → ex:part-a → ex:hasPart → ex:screw
ex:compounded-thing → ex:hasPart → ex:part-b → ex:hasPart → ex:screw

This illustrates why editing along complex property paths is non-trivial: it can be unclear which intermediate nodes or triples correspond to a user’s intended modification.

Built-in Widgets

Editors

The following subsections enumerate the currently built-in instances of `shui:Editor` from the SHACL UI namespace.

shui:AutoCompleteEditor

Score:

`40` if the property indicates its preference for `shui:AutoCompleteEditor` using a `shui:editor` statement and has a `sh:class` constraint, and the value is an IRI.
`10` if the property has a `sh:nodeKind sh:IRI` and a `sh:class` constraint.

Rendering: An auto-complete field to enter the label of instances of the class specified for the property. For example, if the `sh:class` of the property is `ex:Country` and the user starts typing "Nig", then "Niger" and "Nigeria" would show up as possible choices.

Example of a rendered AutoCompleteEditor

ex:Person-bornIn
	a sh:PropertyShape ;
	sh:path ex:bornIn ;
	sh:class ex:Country ;
	...

Implementations may want to also support the combination of `sh:class` with `sh:node` constraints to further narrow the set of valid values. In this case, the component would filter out any instances of the class that do not conform to the specified node shape. In the following example, the auto-complete would only show countries that have `true` as their value for `ex:sovereign`.

ex:Person-bornIn
	a sh:PropertyShape ;
	sh:path ex:bornIn ;
	sh:class ex:Country ;
	sh:node [
		sh:property [
			sh:path ex:sovereign ;
			sh:hasValue true ;
		]
	] ; ...

shui:BlankNodeEditor

Score:

`40` if the property indicates its preference for `shui:BlankNodeEditor` using a `shui:editor` statement, and the value is a blank node.
`1` if the value is a blank node.

Rendering: A read-only editor that displays the blank node, similar to shui:BlankNodeViewer, yet allows the surrounding user interface to at least provide a delete button.

shui:BooleanEditor

Score:

`40` if the property indicates its preference for `shui:BooleanEditor` using a `shui:editor` statement, and the value is an `xsd:boolean` literal.
`20` if the value is an `xsd:boolean` literal.
`10` if the property has a `sh:datatype xsd:boolean` constraint.

Rendering: A widget for editing boolean values, typically rendered as a checkbox, toggle switch, or select dropdown offering true and false, and, where the property is optional, optionally an additional control state representing the absence of a value.

The exact rendering of the `BooleanEditor` may vary between implementations depending on the complexity and requirements of the use case. In particular, implementations should carefully distinguish between optional and required boolean properties: for optional properties, the absence of a value is semantically different from the value `false`, and an implementation may therefore render a select dropdown with three choices (e.g., `true`, `false`, and `none`) where `none` represents no value; for required properties, where a value must always be present, a checkbox or toggle switch may be appropriate. Implementations may choose the most suitable rendering approach, provided this semantic distinction is preserved.

Example of a BooleanEditor rendered as select dropdown

ex:Person-married
	a sh:PropertyShape ;
	sh:path ex:married ;
	sh:datatype xsd:boolean ;
	...

shui:DatePickerEditor

Score:

`40` if the property indicates its preference for `shui:DatePickerEditor` using a `shui:editor` statement, and the value is an `xsd:date` literal.
`20` if the value is an `xsd:date` literal.
`10` if the property has a `sh:datatype xsd:date` constraint.

Rendering: A calendar-like date picker.

ex:Person-dateOfBirth
	a sh:PropertyShape ;
	sh:path ex:dateOfBirth ;
	sh:datatype xsd:date ;
	...

shui:DateTimePickerEditor

Score:

`40` if the property indicates its preference for `shui:DateTimePickerEditor` using a `shui:editor` statement, and the value is an `xsd:dateTime` literal.
`20` for `xsd:dateTime` literals.
`10` if the property has a `sh:datatype xsd:dateTime` constraint.

Rendering: A calendar-like date picker including a time selector.

Example of a rendered DateTimePickerEditor

ex:Customer-lastVisitTime
	a sh:PropertyShape ;
	sh:path ex:lastVisitTime ;
	sh:datatype xsd:dateTime ;
	...

shui:DetailsEditor

Score:

`40` if the property indicates its preference for `shui:DetailsEditor` using a `shui:editor` statement, and the value is an IRI or a blank node.
`0` if the value is an IRI or a blank node.

Rendering: Typically rendered as a nested form that allows editing the properties of the value node inline within the surrounding form. The fields of the nested form are determined by the shape that applies to the value node. This shape may be specified explicitly (e.g., via `sh:node` or other mechanisms that associate a shape with the value), or implicitly via constraints such as `sh:class`. Alternatively, nested fields may be defined directly on the surrounding property shape using `sh:property`.

When rendered as a nested form, the implementation recursively evaluates the applicable shape of the value node and renders its declared property shapes as sub-fields. Implementations may alternatively render the details in a separate dialog or dedicated view, provided that the editing semantics remain equivalent.

This editor is particularly useful for blank nodes or tightly coupled resources that are typically created and edited only in the context of their parent resource. However, it may also be used for IRIs referencing other resources.

ex:Product
	a owl:Class ;
	a sh:NodeShape ;
	rdfs:label "Product" ;
	rdfs:subClassOf owl:Thing ;
	sh:property ex:Product-weight .

ex:Product-weight
	a sh:PropertyShape ;
	sh:path ex:weight ;
	shui:editor shui:DetailsEditor ;
	shui:viewer shui:DetailsViewer ;
	sh:description "A blank node with a numeric field and a unit which is one of the QUDT mass units." ;
	sh:maxCount 1 ;
	sh:name "weight" ;
	sh:node ex:ValueWithWeight ;
	sh:nodeKind sh:BlankNode .

ex:ValueWithWeight
	a sh:NodeShape ;
	rdfs:label "Value with weight" ;
	sh:property ex:ValueWithWeight-numericValue ;
	sh:property ex:ValueWithWeight-unit .

ex:ValueWithWeight-numericValue
	a sh:PropertyShape ;
	sh:path ex:numericValue ;
	sh:datatype xsd:decimal ;
	sh:maxCount 1 ;
	sh:minCount 1 ;
	sh:name "numeric value" .

ex:ValueWithWeight-unit
	a sh:PropertyShape ;
	sh:path ex:unit ;
	sh:class <http://qudt.org/schema/qudt/Unit> ;
	sh:maxCount 1 ;
	sh:minCount 1 ;
	sh:name "unit" ;
	sh:node [
		rdfs:label "Permissible values must have quantity kind Mass." ;
		sh:property [
			sh:path <http://qudt.org/schema/qudt/hasQuantityKind> ;
			sh:hasValue <http://qudt.org/vocab/quantitykind/Mass> ;
		] ;
	] .

This widget requires that the surrounding property (`ex:weight`, above) declares `sh:nodeKind sh:BlankNode` and also has a `sh:node` constraint that points at a node shape that declares the properties that shall be editable.

shui:EnumSelectEditor

Score:

`40` if the property indicates its preference for `shui:EnumSelectEditor` using a `shui:editor` statement and has a `sh:in` constraint.
`30` if the property has a `sh:in` constraint.

Rendering: A drop-down editor for enum fields (based on the `sh:in` list, in that order).

ex:AustralianAddressShape-addressRegion
	a sh:PropertyShape ;
	sh:path schema:addressRegion ;
	sh:in ( "ACT" "NSW" "NT" "QLD" "SA" "TAS" "VIC" "WA" ) ;
	...

shui:InstancesSelectEditor

Score:

`40` if the property indicates its preference for `shui:InstancesSelectEditor` using a `shui:editor` statement and has a `sh:class` constraint, and the value is an IRI.
`0` if the property has a `sh:class` constraint.

Rendering: A drop-down editor for all instances of the target class (based on `sh:class` of the property). Typically only used for classes that have few instances.

ex:Person-homeCountry
	a sh:PropertyShape ;
	sh:path ex:homeCountry ;
	sh:class ex:Country ;
	shui:editor shui:InstancesSelectEditor ;
	...

shui:IRIEditor

Score:

`40` if the property indicates its preference for `shui:IRIEditor` using a `shui:editor` statement, and the value is an IRI.
`20` if the value is an IRI, and the property has a `sh:nodeKind sh:IRI` and no `sh:class` constraint.
`10` if the property has a `sh:nodeKind sh:IRI` constraint and no `sh:class` constraint.
`0` if the value is an IRI.

Rendering: An input field to enter the IRI of a resource, e.g., as value of `rdfs:seeAlso` or to enter the URL of an image on the web.

ex:Thing-seeAlso
	a sh:PropertyShape ;
	sh:path rdfs:seeAlso ;
	sh:nodeKind sh:IRI ;
	shui:editor shui:IRIEditor ;
	...

shui:NumberFieldEditor

Score:

`40` if the property indicates its preference for `shui:NumberFieldEditor` using a `shui:editor` statement, and the value is an `xsd:decimal`, `xsd:integer`, `xsd:double`, or `xsd:float` literal.
`20` if the value is an `xsd:decimal`, `xsd:integer`, `xsd:double`, or `xsd:float` literal.
`10` if the property has a `sh:datatype xsd:decimal`, `xsd:integer`, `xsd:double`, or `xsd:float` constraint.

Rendering: An input field to enter numeric values. The field should only allow entering valid numeric values according to the specified datatype. If no `sh:datatype` constraint is specified, `xsd:decimal` is assumed to be the default numeric datatype.

ex:Product-price
    a sh:PropertyShape ;
    sh:path ex:price ;
    sh:datatype xsd:decimal ;
    shui:editor shui:NumberFieldEditor ;
    ...

shui:RichTextEditor

Score:

`40` if the property indicates its preference for `shui:RichTextEditor` using a `shui:editor` statement, and the value is an `rdf:HTML` literal.
`20` if the value is an `rdf:HTML` literal.
`10` if the property has a `sh:datatype rdf:HTML` constraint.

Rendering: A rich text editor to enter the lexical value of a literal and a drop-down to select language. The selected language is stored in the HTML `lang` attribute of the root node in the HTML DOM tree.

ex:Concept-definition
	a sh:PropertyShape ;
	sh:path skos:definition ;
	sh:datatype rdf:HTML ;
	...

shui:SubClassEditor

Score:

`40` if the property indicates its preference for `shui:SubClassEditor` using a `shui:editor` statement and has a `sh:rootClass` constraint, and the value is an IRI.

Rendering: This can be an auto-complete widget to select a class, a class hierarchy widget, or a combination thereof. The permissible values are a given class or its subclasses, defaulting to `rdfs:Resource`. This is typically used with `sh:rootClass` to allow the user to select a subclass of the given root class.

ex:Drug-impactedCell
	a sh:PropertyShape ;
	sh:path ex:impactedCell ;
	sh:rootClass obo:CL_0000000 ;
	shui:editor shui:SubClassEditor ;
	...

shui:TextAreaEditor

Score:

`-1` if the property has a `sh:singleLine true` constraint.
`40` if the property indicates its preference for `shui:TextAreaEditor` using a `shui:editor` statement.
`30` if the value is an `xsd:string` literal and the property has a `sh:singleLine false` constraint.
`20` if the value is an `xsd:string` literal.
`5` if the property has `xsd:string` among the permissible datatypes.
`0` if the property has a `sh:singleLine false` constraint.
~~0 otherwise.~~

Rendering: A multi-line text area to enter the value of a literal.

ex:Country-description
	a sh:PropertyShape ;
	sh:path ex:description ;
	sh:datatype xsd:string ;
	sh:singleLine false ;
	...

shui:TextAreaWithLangEditor

Score:

`-1` if the property has a `sh:singleLine true` constraint.
`40` if the property indicates its preference for `shui:TextAreaWithLangEditor` using a `shui:editor` statement.
`30` if the value is an `rdf:langString` literal and the property has a `sh:singleLine false` constraint.
`20` if the value is an `rdf:langString` literal.
`5` if the property has `rdf:langString` among the permissible datatypes.
`1` if the property has `xsd:string` among the permissible datatypes.

Rendering: A multi-line text area to enter the value of a literal and a drop-down to select a language.

Example of a rendered TextAreaWithLangEditor

ex:Country-description
	a sh:PropertyShape ;
	sh:path ex:description ;
	sh:datatype rdf:langString ;
	sh:singleLine false ;
	...

shui:TextFieldEditor

Score:

`-1` if the property has a `sh:singleLine false` constraint.
`40` if the property indicates its preference for `shui:TextFieldEditor` using a `shui:editor` statement.
`30` if the value is an `xsd:string` literal.
`10` if the property has `xsd:string` among the permissible datatypes.
`0` if the property has a custom datatype (not from `xsd` or `rdf` namespaces but for example `geo:wktLiteral`).

Rendering: An input field to enter the value of a literal, without the ability to change language or datatype.

ex:Country-code
	a sh:PropertyShape ;
	sh:path ex:code ;
	sh:datatype xsd:string ;
	...

shui:TextFieldWithLangEditor

Score:

`-1` if the property has a `sh:singleLine false` constraint.
`40` if the property indicates its preference for `shui:TextFieldWithLangEditor` using a `shui:editor` statement.
`30` if the value is an `rdf:langString` literal.
`10` if the property has `rdf:langString` among the permissible datatypes.
`1` if the property has `xsd:string` among the permissible datatypes.

Rendering: A single-line input field to enter the value of a literal and a drop-down to select language, which is mandatory unless `xsd:string` is among the permissible datatypes.

Example of a rendered TextFieldWithLangEditor

ex:Concept-prefLabel
	a sh:PropertyShape ;
	sh:path skos:prefLabel ;
	sh:datatype rdf:langString ;
	...

Viewers

The following subsections enumerate the currently built-in instances of `shui:Viewer` from the SHACL UI namespace.

shui:BlankNodeViewer

Score:

`30` if the property indicates its preference for `shui:BlankNodeViewer` using a `shui:viewer` statement, and the value is a blank node.
`1` if the value is a blank node.

Rendering: A human-readable label of the blank node. For example, if the blank node is an OWL restriction, then Manchester Syntax could be used. If the blank node is a SPIN RDF expression, then a SPARQL string could be produced. This rendering may include hyperlinks to other resources that can be reached from the blank node.

shui:DetailsViewer

Score:

`30` if the property indicates its preference for `shui:DetailsViewer` using a `shui:viewer` statement, and the value is an IRI or a blank node.
`0` if the value is an IRI or a blank node.

Rendering: Displays the details of the value node as a nested, form-like structure within the surrounding view. The properties shown are determined by the shape that applies to the value node. This may be specified explicitly (e.g., via sh:node or other mechanisms that associate a shape with the value), inferred via constraints such as sh:class, or defined directly as nested sh:property declarations on the property shape.

When rendered as a nested display, the implementation recursively evaluates the applicable shape and presents its property shapes as structured subsections of the parent form. Implementations may vary in layout and visual styling, but the logical grouping and recursive traversal of the applicable shape SHOULD be preserved.

shui:HTMLViewer

Score:

`30` if the property indicates its preference for `shui:HTMLViewer` using a `shui:viewer` statement, and the value is an `rdf:HTML` or `xsd:string` literal.
`20` if the value is an `rdf:HTML` literal.

Rendering: The literal parsed into HTML DOM elements. Hyperlinks in the HTML may get redirected to select resources within the same application. Also displays the language if the HTML has a `lang` attribute on its root DOM element.

shui:HyperlinkViewer

Score:

`30` if the property indicates its preference for `shui:HyperlinkViewer` using a `shui:viewer` statement, and the value is an `xsd:anyURI` or `xsd:string` literal.
`20` if the value is an `xsd:anyURI` literal.
`0` if the value is an `xsd:string` literal.

Rendering: A clickable hyperlink to the specified URI/URL.

shui:ImageViewer

Score:

`30` if the property indicates its preference for `shui:ImageViewer` using a `shui:viewer` statement.
`20` if the value is an IRI or a literal that has a case-insensitive recognized image file extension ending such as `.png`, `.jpg`, `.jpeg`, `.gif`, or `.svg`.

Rendering: The image at the given URL, using `<img>` in HTML.

shui:IRIViewer

Score:

`30` if the property indicates its preference for `shui:IRIViewer` using a `shui:viewer` statement, and the value is an IRI.
`1` if the value is an IRI.

Rendering: As a hyperlink to that IRI. Also includes other ways of interacting with the IRI, such as opening a nested summary display.

shui:LabelViewer

Score:

`30` if the property indicates its preference for `shui:LabelViewer` using a `shui:viewer` statement, and the value is an IRI.
`10` if the value is an IRI.

Rendering: As a hyperlink to that URI based on the display label of the resource. The display label is typically based on the most suitable `rdfs:label` or `skos:prefLabel` for the current user, based on their language preferences. Also includes other ways of interacting with the URI, such as opening a nested summary display.

shui:LangStringViewer

Score:

`30` if the property indicates its preference for `shui:LangStringViewer` using a `shui:viewer` statement.
`20` if the value is an `rdf:langString` literal.

Rendering: As the text plus a language indicator (flag or language tag).

shui:LiteralViewer

Score:

`30` if the property indicates its preference for `shui:LiteralViewer` using a `shui:viewer` statement.
`1` if the value is a literal.

Rendering: The lexical form of the value.

shui:ValueTableViewer

This is a Multi Viewer.

Score:

`30` if the property indicates its preference for `shui:ValueTableViewer` using a `shui:viewer` statement.

Rendering: All values of the property at the focus node are rendered into a single (HTML) table that can be scrolled and paged independently of the rest of the form. Each value becomes one row. The columns of the table are derived from the node shape specified using `sh:node` for the property, in the order specified using `sh:order`.

In this example, we have used a `sh:values` rule to infer the values of the first column. In this case, the values are simply pointing back to the focus node of each row, using `sh:this`. Note that `sh:targetClass` is needed to get this inference correctly.

skos:Concept
    sh:property ex:Concept-broader-inverse .

ex:Concept-broader-inverse
    a sh:PropertyShape ;
    sh:path [ sh:inversePath skos:broader ] ;
    sh:group skos:HierarchicalRelationships ;
    sh:name "narrower (table)" ;
    shui:viewer shui:ValueTableViewer ;
    sh:node ex:ConceptTableShape .

ex:ConceptTableShape
    a sh:NodeShape ;
    sh:targetClass skos:Concept ;
    rdfs:comment "A node shape defining the columns for a shui:ValueTableViewer." ;
    rdfs:label "Concept table shape" ;
    sh:property ex:ConceptTableShape-self ;
    sh:property ex:ConceptTableShape-type ;
    sh:property ex:ConceptTableShape-altLabel .

ex:ConceptTableShape-self
    a sh:PropertyShape ;
    sh:path ex:self ;
    sh:description "This column is used to render the (narrower) concept itself." ;
    sh:name "narrower concept" ;
    sh:nodeKind sh:IRI ;
    sh:order "0"^^xsd:decimal ;
    sh:values sh:this .

ex:ConceptTableShape-type
    a sh:PropertyShape ;
    sh:path rdf:type ;
    sh:description "The second column shows the type of each value." ;
    sh:name "type" ;
    sh:nodeKind sh:IRI ;
    sh:order "1"^^xsd:decimal .

ex:ConceptTableShape-altLabel
    a sh:PropertyShape ;
    sh:path skos:altLabel ;
    sh:description "The third column shows the alternative labels." ;
    sh:name "alt labels" ;
    sh:or ( [ sh:datatype xsd:string ] [ sh:datatype rdf:langString ] ) ;
    sh:order "2"^^xsd:decimal .

Property Roles

RDF resources commonly use properties to specify labels, descriptions, and other information needed for rendering, which user-interface engines depend on to render structured content. However, the vocabularies defining these properties vary across domains and communities. To ensure consistent interpretation, property shapes can be annotated with explicit roles for elements such as labels, descriptions, and other rendering properties.

This section introduces Property Roles for annotating SHACL property shapes, along with several built-in property roles defined in the SHUI namespace. Property Roles are defined in the SHUI namespace and define the class shui:PropertyRole and the property shui:propertyRole.

Direct Role Annotation

Property roles can be annotated on property shapes by using the shui:propertyRole predicate and linking directly to a property role instance. SHACL renderers may use such direct annotations to drive the way specific user-interface elements are displayed.

It is possible but not recommended to assign the same property role to multiple property shapes that apply to the same focus node using the direct role annotation form. When this is done, the resulting behavior is undefined.

The example below illustrates the common case where a property shape is directly annotated with shui:LabelRole. This informs user-interfaces that the shape's value nodes represent human-readable labels for resources.

Qualified Role Annotation

When multiple predicates serve the same role in the data but require a defined precedence, the qualified role annotation should be used.

For property shapes annotated with the same role, user interfaces should prefer the shape with the smallest sh:order value. If multiple shapes share the same role, they must be sorted and processed in ascending order of their sh:order values. In addition, any property shape using a qualified role annotation is always preferred over a shape using a direct, unqualified role annotation.

The qualified role annotation can also be expressed using triple annotations. SHACL Renderers that support RDF 1.2 should support the triple annotation syntax in addition to the RDF 1.1-compatible qualified role annotation syntax.

Built-in Property Roles

The following sections define the instances of shui:PropertyRole in the SHUI namespace. These property roles MUST be supported by SHACL Renderers. Additional property roles may be defined in other namespaces.

shui:LabelRole

The shui:LabelRole is used to identify properties whose values serve as human-readable display labels. Common examples of display label predicates include rdfs:label, skos:prefLabel, and schema:name.

Definitions

shui:PropertyRole Class

The class of roles that a property shape may take with respect to its focus nodes. It is not required, but recommended, that roles defined in other namespaces subclass shui:PropertyRole.

shui:propertyRole Property

The property used to annotate property shapes with roles. Its value is expected to be either an instance of shui:PropertyRole or a resource that itself declares a shui:propertyRole and an associated sh:order value.

Document Outline

Introduction

Scope

Terminology

Document Conventions

RDF Abstract Model Compatibility

Widgets

Editors

Viewers

Core Constraints

Property Paths

View Mode

Predicate and Inverse Paths

Complex Paths

Edit Mode

Predicate and Inverse Paths

Alternative Paths

Other Complex Paths

Built-in Widgets

Editors

shui:AutoCompleteEditor

shui:BlankNodeEditor

shui:BooleanEditor

shui:DatePickerEditor

shui:DateTimePickerEditor

shui:DetailsEditor

shui:EnumSelectEditor

shui:InstancesSelectEditor

shui:IRIEditor

shui:NumberFieldEditor

shui:RichTextEditor

shui:SubClassEditor

shui:TextAreaEditor

shui:TextAreaWithLangEditor

shui:TextFieldEditor

shui:TextFieldWithLangEditor

Viewers

shui:BlankNodeViewer

shui:DetailsViewer

shui:HTMLViewer

shui:HyperlinkViewer

shui:ImageViewer

shui:IRIViewer

shui:LabelViewer

shui:LangStringViewer

shui:LiteralViewer

shui:ValueTableViewer

Property Roles

Direct Role Annotation

Qualified Role Annotation

Built-in Property Roles

shui:LabelRole

Definitions

shui:PropertyRole Class

shui:propertyRole Property

Summary of Syntax Rules from this Specification

Security Considerations

Privacy Considerations

Internationalization Considerations

Acknowledgements

hello