UI: Inventory of widgets

[danielbeeke]

Issue: Expansion of shui Viewers, Editors, and Property Roles

Description

To improve the utility of the shui namespace, we propose the inclusion of additional standard viewers and editors. While the current import of dash provides a strong foundation, modern RDF applications frequently require specialized handling for Markdown, Geospatial data, and complex HTML5 media elements.

Proposed Viewers & Editors

Category	Component	Description
Media	shui:VideoViewer	Handles subtitles, captions, and sources via property roles.
	shui:AudioViewer	Standard audio controls and source management.
	shui:PictureViewer	Optimized for and with alt-text.
	shui:IIIfViewer	Specifically for IIIF manifest/image integration.
Geospatial	shui:SimpleGeoViewer	Basic polygon/shape rendering without maplayer.
	shui:MapGeoViewer	Interactive map view for one single point or one single polygon.
	shui:GeoMultiViewer	Layered map view for multiple geo-entities. Uses property roles
	shui:GeoEditor	Input for WKT or GeoJSON strings.
Code/Markup	shui:MarkdownViewer *	Renders Markdown literals as HTML.
	shui:MarkdownEditor *	WYSIWYG or side-by-side Markdown editor.
	shui:MermaidViewer *	Renders diagram code into visual charts.
	shui:JSONViewer	Formatted view for rdf:JSON literals.
	shui:SPARQLViewer *	Syntax highlighting for SPARQL queries.

---

Handling Complex Media with shui:propertyRole

For complex HTML elements like <picture> or <video>, a flat literal is often insufficient. We propose leveraging shui:propertyRole to map specific properties of a shui:NodeShape to the internal requirements of the viewer.

Example: Picture Multi-Viewer Logic

A NodeShape representing an image could utilize the following new roles:

• shui:AltRole: Maps a property to the alt attribute.

• shui:SrcsetRole: Maps a property to responsive image sources.

• shui:CreditRole: For attribution or captions.

---

Canonical IRIs for Literals (Question for the Group)

To implement the viewers marked with an asterisk (*), we need to finalize the canonical IRIs for these datatypes. Potential candidates include:

• Markdown: https://w3id.org/formats/Markdown (or a specific IANA-based URN)

• Mermaid: https://mermaid.js.org/datatype (?)

• SPARQL: http://www.w3.org/ns/formats/SPARQL_Query

Proposed New Roles

• shui:AltRole

• shui:SubTitleRole

• shui:CreditRole

• shui:SrcsetRole

• shui:GeoRole (To differentiate between primary coordinates and metadata)

---

Discussion Points

1. Core widgets vs. comunity: Which of these potential widgets should be in SHACL 1.2 UI?
2. Missing widgets: Do you have additional widgets that could be in SHACL 1.2 UI?

[nicholascar]

If additions to the inventory are expected after the publication of SHACL UI, then it needs to be hosted in a location that can be edited after the close of the WG. We have a place for this:

• https://github.com/w3c/shacl-resources

So we may need a basic list for the specification document and then a larger, open-ended, superset for that shacl-resources repo.

If PRs are created for this Issue @edmondchuc @bergos & @danielbeeke, please crosslink the two locations.

[tfrancart]

I don't understand the inclusion of the tool-specific shui:MermaidViewer and I suggest to generalize it to something like shui:DiagramRenderingViewer or shui:DiagramNotationViewer or similar.

I don't understand the difference between shui:SimpleGeoViewer , shui:MapGeoViewer and ̀shui:GeoMultiViewer, the associated documentation should make explicit what the difference is.

In addition to shui:JSONViewer for rdf:JSON literals, a similar shui:XMLViewer could be added for rdf:XMLLiteral datatype.

Could a default mapping between datatypes and viewers or editors be provided ? so that an application can rely on this default mapping and select the proper viewer or editor only by looking at the datatype ?

[danielbeeke]

About shui:MermaidViewer:

I personally think it should be in the community space instead of the spec. That way it may be specific: allowing for Widgets that are easy to implement and that work for specific data types.

For the Geo types I improved the table a bit.

For this default mapping we have a structure in place. We are working on defining scores for widgets in RDF and a scoring system. In there this mapping can easily be defined. I suggest we keep it out of scope for this issue.