Real ESPR/battery SHACL shapes + verified fixtures (starter, non-normative)

[opendpp-node]

Real ESPR/battery SHACL shapes + wired tests (starter, non-normative)

Follow-up from our call: shapes contributed with fixtures and the tests wired in, ready for review.

Motivation

The bundled SHACL templates (core/src/test/resources/shacl-templates/{battery_pass,electronics,vehicle}_shacl.ttl)
use placeholder http://example.org/… namespaces, so they can't validate a real passport.
This adds a starter shapes set authored against an actual implementer's DPP vocabulary
(OpenDPP's public application/ld+json passport), so the repo ships something that validates
a real document out of the box.

What's added

• core/src/test/resources/shacl-templates/opendpp_battery_shacl.ttl — NodeShapes for the DPP
  root + battery/ESPR metadata block (lifecycle status, economic operator, manufacturing
  facility, carbon-footprint presence, durability, material composition, battery category,
  rated capacity, seal material).
• core/src/test/resources/json-ld/valid-opendpp-battery-ld.json — a real OpenDPP battery
  passport that conforms.
• core/src/test/resources/json-ld/invalid-opendpp-battery-ld.json — same passport with
  status set to BOGUS_STATUS and metadata.durability removed.
• ValidatorServiceTest#testOpenDPPBatteryJSONLDValidation — valid passport conforms.
• ValidatorServiceTest#testFailingOpenDPPBatteryJSONLDValidation — invalid passport yields
  exactly 2 violations, on dpp:status (enum) and dpp:metadata (fails
  BatteryMetadataShape).
• MockShaclRepository.findBestMatch routes inputs whose type/vocabulary belong to the
  OpenDPP vocabulary to the new template — vehicle behaviour unchanged, all existing
  tests untouched and passing.

Verified locally (JDK 21, ./mvnw test, full reactor)

ValidatorServiceTest: tests=16, failures=0, errors=0, skipped=0   (14 existing + 2 new)
all modules green (core, api/rest, datastores)

Design notes

• Hermetic fixtures: the passport's @context is fully inline (no remote context URL), so
  neither the titanium metadata extraction nor Jena's JSON-LD parsing performs any network
  fetch at test time — consistent with the existing vehicle-ld.json fixture style.
• Shapes target the RDF the passport expands to under its inline @context. Only terms in
  that context survive JSON-LD→RDF expansion, so nested economicOperator / Facility inner
  fields are presence-checked rather than class-targeted (class-targeting unexpanded
  nodes would be unsound).
• Honest namespaces throughout (opendpp-node.eu/…) — no example.org, and no borrowed
  eCl@ss/IDTA identifiers.

Scope / claims

Non-normative, starter. These are OpenDPP-authored shapes offered as a contribution — not
an EU / CIRPASS-2 conformance oracle, not a claim of Battery-Regulation completeness. Glad to
extend the same pattern to the pilot chains (electronics / textiles / tyres / construction).

Checklist

• New functionality covered by tests (valid conforms / invalid violates, exact paths asserted)
• Existing test suite passes (./mvnw test, full reactor, JDK 21)
• No example.org / unverified IRDIs introduced
• Maintainer review

— Giovanni Savastano · OpenDPP (opendpp-node.eu)

[opendpp-node]

Following up on our call today: wired the tests in (valid conforms; invalid → exactly 2 violations on dpp:status + dpp:metadata), made the fixtures hermetic (inline @context only, no network fetch at parse time), and rebased on latest main. Full reactor green locally on JDK 21 — marking ready for review. Thanks for enabling CI on this!

[marco-volpini]

Looks good to me