- TODO: provide an introduction, use cases, and examples on SHACL UI basics.
+
+
Getting Started with SHACL UI
+
+ This section introduces the basics of SHACL UI through a simple example.
+ By the end, you will understand how a SHACL Renderer uses SHACL Core
+ concepts to generate user interface forms, and how SHACL UI annotations
+ can tailor those forms to your use case.
+
+
+
+ A goal of SHACL UI is to provide users with a simple way to generate
+ usable forms from a shapes graph and a data graph. This allows SHACL
+ shapes authors who are not necessarily software developers to inspect
+ how their shapes are interpreted as user interface forms, gather
+ feedback from collaborators, and prototype ideas without requiring
+ extensive software development effort.
-
Add conceptual model diagram and UI mockups to illustrate the concepts.
+
+
Data Graph Only
+
+
+ Let's start with defining a simple data graph that we'll use
+ throughout this section.
+
+
+
+
+
+ With just the data graph, we have enough information for a SHACL
+ Renderer to generate a simple editable form.
+
+
+
+
+
+ There are a few SHACL UI concepts working together to render this
+ form. First, the labels in the form for the resource name and its
+ properties use Label Resolution to generate human-readable
+ labels. Second, the Scoring System
+ determines the most suitable editor widgets to render. Lastly, the
+ Scoring System has selected two widgets:
+ shui:DatePickerEditor
+ for the birth date field and
+ shui:TextFieldEditor for
+ the remaining fields.
+
+
+
+
+ The resource ex:TimBL is displayed as
+ Tim B L.
+
+
+ The resource's properties are inherently unordered, so the
+ application has chosen to display them alphabetically.
+ In the next example, we will use SHACL annotations to define a more
+ logical ordering.
+
+
+ Given that the value of the birth date field is an
+ xsd:date, the Scoring System has determined that the
+ shui:DatePickerEditor widget is the most appropriate.
+ Note that date widgets may perform localized date formatting, so
+ for a user in Australia, the date may be displayed as
+ DD-MM-YYYY.
+
+
+ All other values are xsd:string, so the Scoring System
+ has selected shui:TextFieldEditor as the most
+ suitable widget for them.
+
+
+
+
+
+
Adding a Shapes Graph
+
+ Now that we've seen how a SHACL Renderer can produce an editable form
+ from only a data graph, let's see how adding a shapes graph that
+ targets the resource affects the result.
+
+
+
+
+
+ With both the data graph and shapes graph provided to the SHACL
+ Renderer, the editable form can use shape constraints for input
+ validation; see the related
+ Displaying Validation
+ Results pattern. The renderer also uses
+ sh:group and sh:order annotations to
+ control the form layout. In this example, the name-related properties
+ are grouped into a Name section and ordered
+ according to their sh:order values, while the birth
+ date is rendered separately because it does not belong to a group.
+
+
+
+ The same shape also introduces simple cardinality constraints.
+ sh:minCount 1 marks the given name and family name as
+ required fields, while sh:maxCount 1 tells the renderer
+ that those fields and the birth date should be edited as single values.
+ Properties without sh:minCount remain optional, and
+ properties without sh:maxCount 1 may be rendered with
+ controls for adding more than one value.
+
+
+
+
+
+
+
Computed Resource Labels
+
+ The data graph contains enough information to display a more useful
+ resource label than the resource's local name. Instead of rendering
+ the node as Tim B L, the shapes graph can define
+ a computed rdfs:label using a node expression. Label
+ Resolution then uses this computed label as the resource's display
+ name.
+
+
+
+
+
+ The rendered form now uses the computed rdfs:label as
+ the resource label, so the resource is displayed by its full name
+ rather than its local name.
+
+
+
+
+
+
+
Nested Resource Forms
+
+
+ RDF data commonly contains relationships between resources. So far,
+ we have shown how a SHACL Renderer generates a form for a single
+ resource. In some cases, however, editing a resource is easier when
+ the form also includes contextual information from related resources.
+ The following example demonstrates this pattern.
+
+
+
+
+
+
+
+ When rendering the form for the ex:TimBL resource, the
+ Scoring System would, by default, render the
+ schema:affiliation value using a
+ shui:IRIEditor, allowing the
+ user to reference another resource without displaying its properties.
+ However, it can be useful to show the ex:W3C resource
+ nested in the same view. To do this, we can configure the shape to
+ prefer the details editor for that property.
+
+
+
+
+
+ With the new property shape, the SHACL Renderer now nests the
+ ex:W3C resource in the same form as the
+ ex:TimBL resource.
+
+
+
+
+
+
+
+
Summary and Next Steps
+
+ This section has shown that a data graph and a SHACL Renderer are
+ enough to produce a usable editable form. Adding a shapes graph,
+ including constraints that are also used in ordinary SHACL validation,
+ lets the SHACL Renderer use those semantics to produce more meaningful
+ forms.
+
+
+
+ We have only briefly touched on cardinality constraints. Other useful
+ but more complex topics include logical constraints and using dynamic
+ SHACL to populate the values for the enum and autocomplete editors.
+ You can find these in the Patterns section.
+
+
+
+
+
+
Rendering Concepts
+
+
+ Add conceptual model diagram on rendering concepts and how they relate
+ to each other as well as other concepts such as widgets.
+
This section explains the UI concepts and how they work together.
@@ -1670,7 +2159,7 @@
Form Messages and Error Handling
-
Displaying Validation Results
+
Displaying Validation Results
This sub-section should address the "Mapping validation results to the form" mentioned in ISSUE 823.
- When rendering the form for the ex:TimBL resource, the
- Scoring System would, by default, render the
- schema:affiliation value using a
+ When rendering the form for the ex:TimBL resource, a
+ property shape for schema:affiliation can identify the
+ value as an IRI using sh:nodeKind sh:IRI. Without an
+ explicit details-editor preference, the Scoring System can then render
+ the value using a
shui:IRIEditor, allowing the
user to reference another resource without displaying its properties.
However, it can be useful to show the ex:W3C resource
- nested in the same view. To do this, we can configure the shape to
- prefer the details editor for that property.
+ nested in the same view. To do this, we can configure the same
+ property shape to prefer the details editor.