Define validation setup: PROF role/validation, cross-profile dependencies, and validation scope levels

[Haigutus]

Problem

The current SHACL validation setup requires manual knowledge of which SHACL rules to load for which instance files, and which RDFS profiles are needed for cross-profile validation. This information should be formally declared in PROF descriptors and SHACL headers to enable automated validation pipelines.

Current PROF role structure

Each PROF file declares resources with four roles:

• prof:role/vocabulary → RDFS vocabulary file (*-Voc-RDFS2020.rdf)
• prof:role/constraints → Simple and Complex SHACL files (*-Con-Simple-SHACL.ttl, *-Con-Complex-SHACL.ttl)
• prof:role/validation → Validation SHACL file (*-Con-Validation-SHACL.ttl) — referenced by URL but not shipped in repo
• prof:role/specification → PDF specification document

The validation role is the key one — it should define the complete validation setup.

Proposal

1. prof:role/validation — what to load for full validation

The Validation SHACL files are referenced in PROF but don't exist in the repo. These should either be created or the validation role should explicitly declare:

• Which constraints SHACL files to apply (Simple, Complex, CrossProfile)
• Which instance profiles must be loaded together (e.g., SV validation needs EQ+SSH+TP)
• Which RDFS vocabularies are needed for class resolution

2. Cross-profile dependency declarations

• Simple rules: single profile only (e.g., AE rules → AE instance)
• Complex/CrossProfile rules need multiple profiles:
  • SV CrossProfile → EQ+SSH+TP+SV
  • SSH Complex (resolved) → EQ+SSH
  • DY CrossProfile → EQ+SV+TP+SSH+DY
• Currently this is implicit in file naming (-CrossProfile-, -NotSolvedMAS-) — no machine-readable declaration
• SHACL headers should declare required profiles via dcterms:requires or owl:imports

3. RDFS dependency chain (abstract class resolution)

• SHACL rules reference abstract CIM classes (IdentifiedObject, PowerSystemResource) defined in shared RDFS
• Each profile's RDFS should declare which other RDFS vocabularies are needed for class hierarchy resolution

4. Validation use cases (levels of scope)

Each level requires progressively more data and SHACL rule sets:

Level	Scope	Example	SHACL rules
1	Single instance file	Belgovia_AE.xml alone	Profile Simple + Complex
2	Instance with resolved references	SSH + EQ it references via dcterms:requires	Profile Simple + Complex + CrossProfile
3	Full IGM	Complete EQ+SSH+TP+SV for one TSO	All profile rules + cross-profile + MAS
4	CGM	Merged grid model across TSOs + boundary data	All IGM rules + cross-border + boundary constraints

The prof:role/validation resource should define which level(s) it targets and what must be loaded.

5. Current SHACL naming convention

• NCP: {Profile}-AP-Con-{Simple|Complex}-SHACL.ttl
• CGMES: {IECStandard}_{Profile}-AP-Con-{Complexity}[-{Variant}]-SHACL.ttl
• Variants: CrossProfile (Explicit/Implicit), NotSolvedMAS, SolvedMAS, InverseAssociation
• Simple = cardinality, datatype, association type validation
• Complex = business rules, allowed values, cross-profile constraints

This naming convention should be documented in the repository README.

Related issues

• Improvement: Consider more explicit SHACL rules context metadata #30 — Consider more explicit SHACL rules context metadata
• Improvement: Add PROF also for CGMES 3.0 #33 — Add PROF also for CGMES

[Haigutus]

Finding: W3C PROF vocabulary limitations for resource-level dependencies

After reviewing the W3C PROF specification, there is no mechanism on prof:ResourceDescriptor to declare which profiles need to be loaded for a specific SHACL resource to work.

The relevant properties are:

• prof:isProfileOf (on Profile) — declares profile-level dependencies (e.g., SV isProfileOf EQ, SSH, TP)
• prof:isInheritedFrom (on ResourceDescriptor) — only indicates inheritance from a base profile, not data dependencies
• dct:conformsTo (on ResourceDescriptor) — indicates what standard the resource conforms to (e.g., SHACL), not what it requires

This means cross-profile dependencies can only be expressed at the Profile level, not per SHACL file. A validation tool must:

1. Read the profile's prof:isProfileOf chain to know which other profiles are needed
2. Infer that role/validation resources (CrossProfile, SolvedMAS) require data from those dependent profiles

An alternative would be to use dct:requires (general Dublin Core property) on ResourceDescriptor to reference required profiles per SHACL file, but this goes beyond the PROF vocabulary.