SHACL UI Task Force Scope

[edmondchuc]

Note

This top-level issue links the working scope of the UI Task Force and the topics up for consideration. You can find further discussions on each topic in the child issues.

[VladimirAlexiev]

WOW! Excellent work, @edmondchuc !
@jeswr We need to do a similar thing for the SHACL-C TF

[tfrancart]

Are all core constraint components supported?

From our experience yypically sh:or can be difficult. We restricted the support of sh:or when it is a union of the same constraint, that is either an or of datatypes, or an or of sh:node or an or of sh:class, but not mixed.

e.g. this would be unsupported:

sh:or (
  [sh:datatype xsd:string ]
  [sh:node ex:myMyshpae]
)

this would be supported

sh:or (
  [sh:node ex:myOtherShape]
  [sh:node ex:myMyshape]
)

What widgets should be included?

Should the exact list of widgets be in scope ? or should only the widget selection mechanism be in scope, but the exact list of widget be left out of scope ?

Also : don't forget some query-specific widgets : for example a widget with 2 calendars to select a date range. This makes sense when querying, but not when editing.

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.

As a preliminary question : how do we know that the address form should be nested ? no information in SHACL tells us this. The address could very well be placed at the same level as the country information. I wish there was something to explicitly annotate property shapes with this "nesting" information. See the JSON-LD framing topic.

(...) vocabulary to customise icons, styling, and colour of the message.

Even before talking about a vocabulary to customise messages, the same apply to shapes : how to associate an icon, a CSS class or a color to a shape ?

Support using Shapes to Frame JSON-LD

While not strictly UI-related, I am interested in this topic, which is linked to the "nesting" question above.
Apart from nesting, one related minor question it raises is also the following : when displaying an entity that does not have property X, do we still want to display "property X :" with no value, or should this be simply hidden ? (JSON-LD @explicit flag)

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

We do use SPARQL for example to populate dropdown lists. Dropdown lists can be populated by a default algorithm that would list all targets of the sh:node shapes, with their labels taken from the property marked with dash:propertyRole dash:LabelRole. However there are a lot of cases where we want to customise the content of the dropdown box. We use SPARQL for this, but this could now be possible with node expressions, I guess ? but we do have fairly complex SPARQL queries, I am not sure the expressivity of node expressions will be sufficient (?)

Support Enabling and Disabling of Shapes and Constraints
Confirm if this topic is needed as it appears SHACL 1.2 Core already supports this.

The 2 scenarios I have in mind are the following:

• Given a SHACL specification for a complete knowledge graph, I need to specify an edit/query form from a subset of it. e.g. only one NodeShape, and on this NodeShape, a subset of property shapes
• Same as above, but by changing some constraints, e.g. cardinalities. Where the original SHACL spec says sh:minCount 0, my form would need to make this property mandatory with sh:minCount 1, or where the original SHACL says sh:node X, I need to replace it with sh:node Y because the set of constraints in the edit/query form are different

[HolgerKnublauch]

We use SPARQL for this, but this could now be possible with node expressions, I guess ? but we do have fairly complex SPARQL queries, I am not sure the expressivity of node expressions will be sufficient (?)

Yes, using https://www.w3.org/TR/shacl12-sparql/#SelectExpression :)