SHACL's Own Profiles

[VladimirAlexiev]

(Assigning to Nick since he's very familiar with Profiles in GeoSPARQL).
cc @HolgerKnublauch, @afs , @gkellogg , @labra .

The charter https://www.w3.org/2024/12/data-shapes.html says

SHACL 1.2 Profiling: This specification will define methods for using SHACL to create formal profiles of (RDF) standards.
This work will likely build on the profile definitions of the W3C's Profiles Vocabulary which has been used extensively with SHACL constraints and the proposed SHACL 1.2 Inferencing Rules.

That part is about using SHACL as an Application Profiling language.
BTW the link there is to https://github.com/w3c/shacl/labels/profiling,
and should be changed to https://github.com/w3c/data-shapes/labels/Profiles (different repo and different label)

---

This issue is about defining formally SHACL's own profiles, i.e. "logically closed" feature sets, so applications can claim conformance to one or multiple profiles.
The same will be used to organize Conformance Tests into groups (#190).

Here is an example:

• Currently we have SHACL and SHACL-AF
• People also talk about SHACL-Core and SHACL-SPARQL
• SPARQL features are split in the two specs:
  • In Core: https://w3c.github.io/data-shapes/shacl/#sparql-constraints, https://w3c.github.io/data-shapes/shacl/#sparql-constraint-components
  • In AF: https://w3c.github.io/data-shapes/shacl-af/#SPARQLTarget, https://w3c.github.io/data-shapes/shacl-af/#SPARQLTargetType (and SPARQL functions, SPARQL rules)
• But arguably, an implementation will implement either both of SPARQL Constraints and Targets, or neither. So they should be in one Profile.
  • A good practice is to put violation finding in SPARQL Target, and the SPARQL Constraint should only populate the result fields (that still runs 1+N queries, but the difficult work is done in the 1 query).
• Also arguably, parametrization (constraint Components and target Types) belong together in one Profile. Eg rdf4j implements SPARQL Constraints and Targets, but not parametrization

In summary:

• we should define a number of Profiles with their formal URLs.
• maybe we should merge the SHACL specs, or re-split along the lines of Profiles

[afs]

This specification will define methods for using SHACL to create formal profiles of (RDF) standards.

I don't understand this part - why is it limited to (RDF) standards / what does that mean?

Support a domain-specific SKOS concept hierarchy (so not an "RDF Standard", it is is written in RDF) that has a "core" and "extended" sections. Is a way to describe, as a profile, the "core" part in-scope of this charter issue?

[gkellogg]

It seems that Profiles should also cover things like w3c/json-ld-syntax#436, where the Profile parameter is used to describe the syntactic shape of the data, as well as the semantic. JSON-LD profiles are used to describe a given document (or to request such a document) based on if it's expanded, compacted, flattened, or framed, and can be used to specify the frame to use when returning such results.

Updates to how browsers handle CORS has complicated using an IRI to identify the profile.

[VladimirAlexiev]

@afs This issue is about grouping SHACL's own features into "profiles".

I think your comment is about using SHACL to describe other profiles.
Since SHACL describes RDF data, I think the clarification "(RDF) standards" is correct.
SKOS is a standard on how to express thesauri in RDF.

[ajnelson-nist]

I confess I'd confused "Profiles" with the 2017 spec's entailments regime support (Section 1.5).

Is there any intent to relate the profiles described in this thread with with entailment regimes?

[VladimirAlexiev]

SHACL uses only rdfs:subClassOf, which is a small part of RDFS.
I don't think there is appetite to enlarge use of reasoning; SHACL wants to do it in its own way, see #215

[afs]

Is there any intent to relate the profiles described in this thread with with entailment regimes?

In this thread, focused on SHACL's features, maybe not. I'm reading that as the profiles for "SHACL-UI" so as not to pick up, say, "SHACL-rules".

As an example of an entailment regime, RDFS is 6 rules, plus rules for meta-modelling, and axiomatic triples.

https://www.w3.org/TR/shacl-af/#rules-execution --

Note that this algorithm only covers a single "iteration" over all rules, without prescribing the behavior if the same rule needs to be applied multiple times after other rules have fired. The latter is left to future work.

My emphasis. Profiles come in for SHACL Rules for rulesets and assumed evaluation. Where the boundaries of WG work are is not clear (to me at least). The WG has finite resources in people and time so choices to be made.

SHACL wants to do it in its own way, see #215

Node Expressions are part of the picture here but they aren't the whole picture (SHACL Rules).

An issue I see arising is that the core phase1 ("a few months") may be dependent on, or at least making assumptions about, phase 2 work e.g. sh:targetNode.

[HolgerKnublauch]

Yes, I think the derived properties from #215 are quite different from graph-level inferences using something like sh:rule. Derived properties can usually be computed on-demand, e.g. whenever a certain property is requested for rendering, while the algorithms that produce additional triples from sh:rules may require more complex infrastructure, e.g. for chaining sh:construct rules. Also, they may be seen as competitor to existing rule frameworks such as RIF and thus attract more external scrutiny.

A decision whether we want to support derived properties needs to be made for Core (soonish) while the graph-level inferences can be decided later and handled by a special interest subgroup. We could check which of the requirements for inferencing can be already covered by the derived properties and which require a full-blown rule engine.

[VladimirAlexiev]

All these are important considerations for #215. But please stop commenting about inference in this issue. Cheers!