[PROF/UI] SHACL UI Profiling Use Case

[edmondchuc]

SHACL UI supports rendering user interface forms based on SHACL shapes, their constraints, and a provided data graph. In practice, implementations may choose to support only a subset of SHACL UI features, or may be limited to doing so. However, the current document does not provide a mechanism for implementations to declare which features they support.

The SHACL UI Task Force would like to present the following use case to the SHACL Profiling Task Force for the section Profiling 3.3: Creating Other Profiles. The goal is to allow SHACL UI implementations to define a profile of SHACL UI that explicitly states the set of features they support.

The proposed approach is to use the mechanism described in Profiling Section 2: Packaging SHACL, enabling implementations to specify supported UI features through the profiling packaging model. To support this, the SHACL UI Task Force would define a SHACL UI ontology that enumerates the features currently defined by the specification. Implementations could then reference and package these features within their own implementation profiles.

This would enable fine-grained interoperability not only at the level of the overall specification, but also at the level of specific features supported by individual implementations.

Use case: Declare a SHACL UI Implementation Profile

Actor: SHACL UI implementation developer

Goal: Declare a machine-readable profile of supported SHACL UI features to enable compatibility assessment by downstream tools and users

Preconditions: A SHACL UI ontology exists that enumerates available features for implementation profiles to reference

Main success scenario:

• The developer identifies the subset of SHACL UI features their tool supports
• The developer uses the SHACL Profiling packaging mechanism to assemble those features into an implementation profile
• The developer publishes the profile alongside their implementation
• A downstream tool or user queries the profile to determine supported features
• The querying tool confirms compatibility with their required feature set

Value: Enables fine-grained interoperability at the implementation level, not just at the specification level

If this proposal is accepted by the Profiling Task Force, the SHACL UI Task Force will define a SHACL UI ontology that enumerates the UI features available for implementation profiles to reference.

[ajnelson-nist]

This sounds reasonable to me. Looking at it the other way - could you prime this with an example of SHACL that would be outside such a profile?

[edmondchuc]

Here's an example. I hope it illustrates the idea clearly, as I may have used some parts of the Profiling document incorrectly.

# Example implementation profile
ex:prof a prof:Profile ;
    prof:isProfileOf <http://w3c.org/ns/shacl-ui/profile> ;
    ... # other profiling parts, such as "has resource" pointing to shui:ont and ex:ont below.
.

# SHACL UI Ontology
shui:ont a owl:Ontology ;
    owl:imports <https://www.w3.org/ns/shacl.ttl> ;
.

shui:AutoCompleteEditor a shui:EditorWidget ;
    rdfs:isDefinedBy shui:ont ;
.

shui:autoCompleteEditorScore40
    a shui:WidgetScore ;
    shui:widget shui:AutoCompleteEditor ;
    shui:score 40 ;
    shui:dataGraphShape shui:isIRI ;
    shui:shapesGraphShape shui:prefersAutoCompleteEditor, shui:hasClassConstraint ;
    rdfs:isDefinedBy shui:ont ;
.

# An implementation profile's indication of element use
ex:ont a owl:Ontology ;
    rdfs:member shui:AutoCompleteEditor ,
         sh:class ,
         shui:autoCompleteEditorScore40 ;
.

Would something like this be supported? Section 2.5 Indicating Element Use states that rdfs:member is used to indicate a SHACL Element, but shui:AutoCompleteEditor and shui:autoCompleteEditorScore40 are not SHACL Elements.

We would like to use the same pattern to specify supported SHACL constraints, SHACL UI widget score instances, and other UI-related features of the specification. Does this seem reasonable, or would it fall outside the scope of SHACL Profiling?