Skip to content

Align ESKA SemanticModel with published SMO in the next core minor version #84

Closed
Closed
Align ESKA SemanticModel with published SMO in the next core minor version#84

Description

@GerhardBalz-Admin
GerhardBalz-Admin
opened on Aug 12, 2026

Goal

Implement the reviewed SKE cross-repository alignment decision now that SMO is fully published and version-active.

The canonical reusable concept is smo:SemanticModel; the already-published ESKA class remains a compatibility surface.

Reviewed decision

SKE PR #18 established that the published definitions are verbatim identical and that seven ESKA execution modes provide no evidence of ESKA-specific narrowing.

The semantic bridge is therefore:

eska:SemanticModel owl:equivalentClass smo:SemanticModel .

This implements the condition anticipated by completed ESKA #57.

Versioning boundary

This is a backward-compatible additive semantic change to the ESKA core and therefore belongs in the next core minor version rather than in immutable core 0.1.0 / repository release eska-v0.1.0.

Candidate next core module version:

core 0.2.0

Do not modify or retag eska-v0.1.0.

Required implementation

  1. add the SMO namespace to the next governed ESKA core source;
  2. assert eska:SemanticModel owl:equivalentClass smo:SemanticModel;
  3. keep eska:SemanticModel resolvable and not deprecated initially;
  4. keep eska:usesSemanticModel unchanged;
  5. record the dependency using dcterms:requires <https://w3id.org/smo/0.1.0> rather than introducing owl:imports by symmetry;
  6. bump the core module to its next minor version and update its owl:versionIRI consistently;
  7. update combined distribution, executable verification, documentation, and publication metadata together;
  8. stage governed repository publication/version routing for the new core version rather than pointing immutable identifiers at mutable main.

Compatibility contract

Existing ESKA consumers may continue using:

https://w3id.org/eska#SemanticModel

The bridge adds machine-readable compatibility with:

https://w3id.org/smo#SemanticModel

No second namespace migration is required.

Explicit non-goals

Do not:

  • deprecate eska:SemanticModel in this first alignment;
  • replace existing eska:usesSemanticModel assertions throughout historical examples merely for cosmetic uniformity;
  • alter immutable eska-v0.1.0;
  • alter immutable smo-v0.1.0;
  • import the entire SMO ontology solely because the class bridge exists;
  • move ESKA-specific concepts such as SemanticCapability, Execution, Result, Verification, Service, Agent, or Deployment into SMO.

Acceptance

  • eska:SemanticModel and smo:SemanticModel are explicitly equivalent in the new governed ESKA core version.
  • eska:SemanticModel remains present and non-deprecated.
  • dependency on immutable SMO v0.1.0 is explicit without owl:imports.
  • ESKA core versioning/publication metadata is internally consistent.
  • executable verification proves the bridge and protects both namespaces.
  • immutable eska-v0.1.0 is byte-for-byte untouched.
  • any new immutable ESKA version route targets a governed release/tag, never main.

Refs SKE PR GerhardBalz/semantic-knowledge-engineering#18, SMO GerhardBalz/semantic-modeling-ontology#11, completed ESKA #57.

Activity

  1. GerhardBalz-Admin commented on Aug 13, 2026

    @GerhardBalz-Admin
    GerhardBalz-Admin
    on Aug 13, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    PR #85 — ready for review

    The core 0.2.0 / SMO compatibility implementation is now fully green after fixing the live W3ID verifier to model the staged publication lifecycle correctly.

    Current head:

    0c1992d9fe1f5ddc02f25dac082d62bc0c7cb853

    Validation evidence:

    • ESKA SMO SemanticModel alignment — run 31672685827 — success;
    • Pizza ESKA reference — run 31672685821 — success across all seven semantic modes and the final publication/live-W3ID checks.

    The live verifier now distinguishes three states explicitly:

    1. current module routes — must be live;
    2. published immutable module-version routes — must remain live and release-backed;
    3. release-pending module versions — must remain unpublished, while their previous immutable version stays live.

    For core specifically:

    current core                     0.2.0
published immutable core         0.1.0 → eska-v0.1.0
core 0.2.0 immutable route       absent by design
next repository release          eska-v0.2.0 — pending

    PR #85 is open, non-draft and mergeable. No immutable release/tag or new W3ID version route is created by this PR.

  2. GerhardBalz-Admin commented on Aug 13, 2026

    @GerhardBalz-Admin
    GerhardBalz-Admin
    on Aug 13, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    Core 0.2.0 bridge merged; publication sequence advanced

    Reviewed PR #85 was squash-merged to main as b6943f49dbd6a19b409b1a83746cbb16eaa42312.

    Post-merge main verification is green:

    • ESKA SMO SemanticModel alignment — run 31673096059 — success;
    • Pizza ESKA reference — run 31673096031 — success.

    The remaining acceptance work is now explicitly staged as:

    1. Publish governed ESKA v0.2.0 release #86 — publish governed eska-v0.2.0 release;
    2. Record ESKA v0.2.0 release evidence after publication #88 — record exact release/tag/backend evidence on main after publication;
    3. Activate immutable ESKA core 0.2.0 W3ID routes #87 — only then activate immutable core 0.2.0 W3ID routes against eska-v0.2.0 and verify them live.

    Release PR #89 is open and validates without creating a release on pull-request events. The actual tag/release creation is guarded to run only after reviewed merge to main.

    Immutable eska-v0.1.0, smo-v0.1.0, and all existing W3ID version routes remain unchanged.

  3. GerhardBalz-Admin commented on Aug 13, 2026

    @GerhardBalz-Admin
    GerhardBalz-Admin
    on Aug 13, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    Status update after reviewed PR #92:

    Keep #84 open until #87 is merged upstream and externally verified; then the ESKA side of SMO downstream alignment is complete.

  4. GerhardBalz-Admin commented on Aug 13, 2026

    @GerhardBalz-Admin
    GerhardBalz-Admin
    on Aug 13, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    Publication handoff — upstream W3ID PR submitted

    The ESKA semantic alignment implementation and governed eska-v0.2.0 release are complete. Release evidence is recorded on main via PR #92 (af35a390a181c86263edbff24bc22b01d7f6520e).

    The final immutable core 0.2.0 routing contribution is now upstream as perma-id/w3id.org#6543, head 0a213385a247adcf3293c1077e9c58e64fda9308.

    At submission it is open, non-draft, mergeable, one commit / two files, with every new immutable backend targeting eska-v0.2.0 and none targeting main.

    Remaining acceptance for #84 is publication-only: upstream merge → external live verification → record route-active evidence. No further ESKA ontology semantic change is required.

  5. GerhardBalz-Admin commented on Aug 13, 2026

    @GerhardBalz-Admin
    GerhardBalz-Admin
    on Aug 13, 2026 – with ChatGPT Codex Connector
    CollaboratorAuthor

    Completion evidence after merged PR #93 (8689f68459b058f7a3ea7c5fee79dc9bfef88b83):

    • eska:SemanticModel owl:equivalentClass smo:SemanticModel is published in governed core 0.2.0;
    • eska:SemanticModel remains present and non-deprecated;
    • immutable SMO v0.1.0 dependency remains explicit via dcterms:requires, without owl:imports;
    • core 0.2.0 version/publication metadata is internally consistent;
    • executable SMO/publication verification is green;
    • immutable eska-v0.1.0 remains untouched;
    • immutable core 0.2.0 W3ID routes are active and externally verified against governed eska-v0.2.0, never mutable main.

    Upstream W3ID PR perma-id/w3id.org#6543 merged as 1230ac37c2100f752e2071606103b81f445d5d5c; GitHub-hosted live verification succeeded before the active-state transition.

    All acceptance criteria are satisfied.

  6. GerhardBalz-Admin
    closed this as completedon Aug 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions