ex:http://example.com/ns#dct:http://purl.org/dc/terms/Within this specification, the following JSON-LD context is used:
@@ -430,7 +434,8 @@Content.
++ 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. +
+ ++ 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. +
+ ++ 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. +
+ + ++ 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. +
+ + ++ In edit mode, property paths determine how changes to data and the creation of new data are applied + through the user interface. +
+ ++ 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. +
+ + ++ 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.
+
+ 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. +
+ + +