[Haigutus]

Counterpart of the 2.4-branch PR #387 (cgmes-3.0_ncp-2.4_tc-1.1, CGMES 3.0 + NCP 2.4 — stays as is) for cgmes-3.0_ncp-2.5_tc-2.0, adapted to the NCP 2.5 line of the application-profiles-library main. Implements #381 on this branch. Fork CI run: https://github.com/Haigutus/relicapgrid/actions/runs/34101124661 (green, four SARIF categories uploaded).

What it adds:

• buildScripts/prof_map.py — maps each instance file's declared profile (md:Model.profile / dcterms:conformsTo) to its SHACL files via the DX-PROF descriptors. For NCP 2.5 it also resolves the role/validation aggregates: their owl:imports closure is resolved by basename in the checkout, and the shapes they mark sh:deactivated are honoured.
• buildScripts/validate_instances.py — validates every Instance/**/*.xml (127 mapped, ~2.5 min): SHACL in cross-file-resolving groups (per area + boundary + CGM assembly; NC per area with Grid context) with per-dataset constraints (sh:minCount/maxCount/sh:closed, ClassCount/PrefixDeclaration, AllowedClasses) evaluated per instance file; a shapes-independent schema-conformance layer; a Model.DependentOn/requires resolvability check. NC additionally runs a dependency-closure comparison (each file over itself + its transitive dcterms:requires), reported as a per-rule diff in the run summary — informational, not uploaded.
• .github/workflows/shacl_validation.yml — one APL checkout (main carries CGMES 3.0 and NCP 2.5), four code-scanning categories (shacl-/schema- × cgmes-3.0/ncp-2.5), full sh:ValidationReports + summary as run artifact.
• buildScripts/schemas/ — the NCP 2.5-dev export schema (triplets format, provenance in SOURCE.json), vendored until a triplets release ships it; triplets pinned to 0.2.0.

Differences from #387: single APL checkout; NC shape sets come from the PROF role/validation aggregates (2.4 had none); the closure comparison run; the vendored schema; and the branch-specific policies below.

Policies encoded (each documented at its constant in validate_instances.py):

• Boundary datasets declare no application profile → validated as CoreEquipment-EU/3.0 until Boundary dataset headers declare no application profile (cgmes-3.0_ncp-2.5_tc-2.0) #395 is fixed (BOUNDARY_PROFILE_FIX).
• Instance/Jotunheim/GridSituation/cimxml/ duplicates Instance/Jotunheim/NetworkCode/ (same dataset UUIDs) → skipped; Dataset_version_dependency/ files validated alone, never in a union frame.
• Skipped with reason in every summary: referenceData (no application profile), Svedala_FAP_PV.xml (Provenance/1.0 has no PROF).

Issues found by this run:

• Boundary dataset headers declare no application profile (cgmes-3.0_ncp-2.5_tc-2.0) #395 — boundary headers lack conformsTo EQ.
• Dataset UUIDs reused as object mRIDs in other files (cgmes-3.0_ncp-2.5_tc-2.0) #396 — two dataset UUIDs reused as object mRIDs (Espheim CO ↔ GridStateAlterationRemedialAction in Espheim RA; IAM 01:30 ↔ AssessedElementWithContingency in Belgovia AE); surfaced by the closure comparison.
• NCP 2.5 validation configuration: unreferenced AllComplex aggregate, missing artifact, unparsable Simple file, undeclared SPARQL prefix NC-AP#22 — NCP 2.5 validation configuration (AllComplex aggregate referenced by no PROF, missing DatasetMetadata validation artifact, unparsable PowerSystemProject Simple, undeclared dcatcim: prefix, imports pinned to main).
• RA #Substation is Description+concrete with no attributes NC-AP#23 — RA #Substation is Description+concrete with no attributes (empty class in the RA RDFS; schema generation emits an empty class).
• Known: SvStatus.ConductingEquipment-valueType/sh:in bulk = SV Simple SHACL: SvStatus.ConductingEquipment-valueType sh:in lists only CsConverter/VsConverter — every other ConductingEquipment reference fails CGMES-AP#11.

Notes for review:

• Closure vs type split differ only in ContingencyEquipment.Equipment-valueType/sh:in (314) and AssessedElement.ConductingEquipment-valueType/sh:in (316): SSH continues EQ objects as <cim:Equipment rdf:about>, so on the area union the target carries types {ACLineSegment, Equipment} and the APL ( assoc rdf:type ) sh:in check fails per SHACL semantics; under the declared requires closure it does not. Left in the code-scanning result for now; the summary table shows the diff.
• SARIF uploads need security-events: write (in the workflow); alerts appear under Security → Code scanning after the first run on the branch, tool triplets-shacl.

[Haigutus]

Snippet of NCP issues report. I am not sure if lang tags should be requiered.