From 0c6be68d897a4829a859ce4ae1133da293d7b695 Mon Sep 17 00:00:00 2001 From: Thomas Bergwinkl Date: Sat, 22 Nov 2025 21:53:30 +0100 Subject: [PATCH] chore: #663 moved built-in widget to separate section --- shacl12-ui/index.html | 857 +++++++++++++++++++++--------------------- 1 file changed, 438 insertions(+), 419 deletions(-) diff --git a/shacl12-ui/index.html b/shacl12-ui/index.html index 51786875..887491b9 100644 --- a/shacl12-ui/index.html +++ b/shacl12-ui/index.html @@ -543,6 +543,375 @@

Editors

If no such value has been specified, the system should pick a suitable default viewer based on the scoring system outlined for each widget.

+ + +
+

Viewers

+

+ The following sub-sections enumerate the currently defined instances of shui:Viewer from the SHACL UI namespace. + A property shape can have an explicitly specified preferred viewer for its values in shui:viewer. + If no such value has been specified, the system should pick a suitable default viewer based on the + scoring system outlined for each widget. +

+

+ Most viewers render a single RDF value on the screen, typically as a single widget. + Form editors offer buttons to edit individual values and to add or delete values. + However, some viewers need to take more complete control over how multiple values of a property at a focus node are rendered. + The only example of such a viewer in SHACL UI is shui:ValueTableViewer, which displays + all values of a property as an HTML table. + In those cases, the notions of generic add and delete buttons do not apply. + Such viewers are called Multi Viewers and are declared instances of shui:MultiViewer instead of shui:SingleViewer. + The equivalent classes for editors are shui:MultiEditor and shui:SingleEditor. +

+
+ + +
+

Core Constraints

+

Content.

+
+ +
+

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. +

+ + +
+ +
+

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. +

+ + +
+
+ +
+

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. +

+ + +
+ +
+

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. +

+ + +
+
+
+ +
+

Built-in Widgets

+ +
+

Editors

+

+ The following sub-sections enumerate the currently built-in instances of shui:Editor from the + SHACL UI namespace. +

shui:AutoCompleteEditor

@@ -947,23 +1316,10 @@

shui:URIEditor

-
+

Viewers

- The following sub-sections enumerate the currently defined instances of shui:Viewer from the SHACL UI namespace. - A property shape can have an explicitly specified preferred viewer for its values in shui:viewer. - If no such value has been specified, the system should pick a suitable default viewer based on the - scoring system outlined for each widget. -

-

- Most viewers render a single RDF value on the screen, typically as a single widget. - Form editors offer buttons to edit individual values and to add or delete values. - However, some viewers need to take more complete control over how multiple values of a property at a focus node are rendered. - The only example of such a viewer in SHACL UI is shui:ValueTableViewer, which displays - all values of a property as an HTML table. - In those cases, the notions of generic add and delete buttons do not apply. - Such viewers are called Multi Viewers and are declared instances of shui:MultiViewer instead of shui:SingleViewer. - The equivalent classes for editors are shui:MultiEditor and shui:SingleEditor. + The following sub-sections enumerate the currently built-in instances of shui:Viewer from the SHACL UI namespace.

shui:BlankNodeViewer

@@ -1099,418 +1455,81 @@

shui:URIViewer

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

-
-
-

shui:ValueTableViewer

-

- This is a Multi Viewer. -

-

- Score: -

    -
  • null, i.e., this should be selected explicitly through a shui:editor 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 dash:applicableToClass or sh:targetClass are 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 ;
-    dash:applicableToClass 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 dash:StringOrLangString ;
-    sh:order "2"^^xsd:decimal .
-
-
-
- -
-

Core Constraints

-

Content.

-
- -
-

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. -

- - -
- -
-

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. -

- - -
+

+
+

shui:ValueTableViewer

+

+ This is a Multi Viewer. +

+

+ Score: +

    +
  • null, i.e., this should be selected explicitly through a shui:editor 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 dash:applicableToClass or sh:targetClass are needed to get this inference correctly. +

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

-            
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.
-                

-
-                
-            

-
-            

-                
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.
-                

-
-                
-            

+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 dash:StringOrLangString ;
+    sh:order "2"^^xsd:decimal .
+