[UI] Use case - UI widgets and data updates with named graphs

[edmondchuc]

Currently, DASH forms provide ways to populate widgets such as the AutoCompleteEditor and ValueTableViewer by declaring shapes and constraints to describe the shape of the data. This works well, and SHACL UI should adopt this. However, this approach assumes all data resides in the data graph when in practice, most datasets are compartmentalised into named graphs for data management purposes. We could build on the work established in DASH forms by adding support for targeting named graphs when populating data for widgets.

SHACL UI could also enable data updates across multiple named graphs through a single form. Without named graph support in SHACL Core, however, this would be difficult to implement and may feel inconsistent. That said, widget-level named graph support could still function effectively. Because data retrieval for widgets is read-only (fetching data to populate them), any updates involving widget data would continue to be written only to the data graph.

Example: When a user is updating an address form, the drop-down list of Australian states and territories (code list) could be retrieved from a named graph separate from the main data graph. Selecting a state or territory from the drop-down would then write the chosen value to the data graph.

Is this a sensible proposal to support named graphs for widgets? And should we explore further on the idea of data updates working across multiple named graphs?

Related:

• Need support for RDF datasets (i.e., graphs, quads) #183

[danielbeeke]

I agree it would be helpful to fetch detail / additional data from a specified named graph.

I recognize the challenge with named graphs. One challenge is, what do you do when all triples of the data graph are from named graph A? Do you write changes back to this named graph A or do you write them to the default graph? We currently do not have a predicate that tells to which named graph you want to write back the changes.

[edmondchuc]

Noting a previous conversation from the mailing list with @HolgerKnublauch on the topic of retrieving remote values (from another named graph) for an editor widget. See https://lists.w3.org/Archives/Public/public-shacl/2024Nov/0009.html. The conversation demonstrates and proposes two solutions:

1. A general solution to retrieve widget values using a custom constraint component
2. A proposal for an optional second parameter to sh:ClassConstraintComponent to specify the named graph