Skip to content

Latest commit

 

History

History
271 lines (172 loc) · 8.24 KB

File metadata and controls

271 lines (172 loc) · 8.24 KB

Semantic Mapping

Meta-Universe Specification

Document ID: MU-V2-FED-006
Title: Semantic Mapping — Mapping Different Vocabularies
Document Class: Normative
Version: 2.0 (Draft)
Status: Working Draft
Normative References: MUC, MMAS, MUFP
Informative References: Identity-Binding.md, Synchronization.md, Meta-Model-Composition
Copyright: © Orkestron.AI
License: Apache-2.0


1. Purpose

This document defines the Semantic Mapping model used by the Meta-Universe Federation Protocol (MUFP).

Semantic Mapping enables independent Universes to exchange knowledge even when they use different vocabularies, Meta-Models or external standards.

Mappings establish semantic correspondence without requiring either participant to modify its own authoritative model.

Crucially, Semantic Mapping in the Meta-Universe maps each local semantics to a shared canonical meaning, not to every other participant in turn. This replaces the quadratic burden of pairwise integration with a linear one against a common reference.


2. Scope

This specification applies to:

  • Universes;
  • Dimensions;
  • Namespaces;
  • Meta-Models;
  • Objects;
  • Relationships;
  • Properties;
  • Events;
  • Projection Profiles;
  • imported standards.

3. Mapping Principles

Every Semantic Mapping SHALL be:

  • explicit;
  • traceable;
  • version-aware;
  • technology independent;
  • non-destructive;
  • explainable.

Mappings SHALL describe semantic correspondence.

They SHALL NOT redefine canonical meaning.


4. Definition

A Semantic Mapping is a first-class semantic artifact describing the relationship between concepts originating from different semantic authorities.

Mappings enable interoperability while preserving sovereignty.


4a. The Canonical-Meaning Hub Model

Naive interoperability maps every model directly to every other model. For N participants this requires up to N × (N − 1) directed mappings — a quadratic, bespoke and unmaintainable burden in which each new participant must integrate separately with all the others.

Pairwise (quadratic)            Canonical hub (linear)

A ── B                                A
│ ╲ ╱ │                               │
│  ╳  │                          B ── Canonical ── D
│ ╱ ╲ │                               │
C ── D                                C

The Meta-Universe SHOULD instead map each local semantics to a canonical meaning recognized by the federation parties. Each participant maintains mappings only between its own model and the canonical meaning; correspondence between any two participants is then composed through the hub. The integration cost becomes linear: a new participant publishes one set of mappings to the canonical meaning and immediately interoperates with all others.

A canonical meaning MAY be an agreed neutral concept, or an external standard adopted as the reference (for example O*NET, ESCO, HR-XML or Schema.org). The hub model SHALL NOT require any participant to adopt the canonical meaning as its own authoritative model; participants map to it, they do not surrender to it.


4b. The Semantic Mapping Registry

To make canonical-meaning mappings reusable rather than re-authored per federation, MUFP introduces the Semantic Mapping Registry: a curated, versioned library of mappings between commonly used standards and canonical meanings.

A Semantic Mapping Registry SHOULD hold reusable mappings such as those between O*NET, ESCO, HR-XML and Schema.org, each carrying its authority, version and provenance. With such a registry, an Employee Meta-Model can interoperate with partners across HR, recruitment and labour-market systems by referencing published mappings to those standards, instead of negotiating a bespoke per-pair integration each time. A registry entry is consulted, not copied; the authoritative models on either side remain unchanged.

Registry mappings SHALL remain subject to every requirement of this document — they are ordinary Semantic Mappings that happen to be published for reuse.


5. Mapping Types

Typical mapping types include:

  • Equivalent
  • Extension
  • Specialization
  • Generalization
  • Derived From
  • Alias
  • Transformation Required
  • Partial Mapping
  • No Known Mapping

Domain standards MAY introduce additional mapping types.


6. Mapping Components

Every Semantic Mapping SHOULD define:

  • canonical identifier;
  • source concept;
  • target concept;
  • mapping type;
  • mapping rationale;
  • confidence (when applicable);
  • governing authority;
  • version;
  • provenance.

7. Mapping Authority

Every Mapping SHALL identify the authority responsible for publishing it.

Mappings MAY be authored by:

  • the authoritative Universe;
  • a federation authority;
  • a standards organization;
  • an agreed neutral steward.

Authority SHALL remain explicit.


8. Version Compatibility

Mappings SHALL identify the versions of both participating semantic models.

Mappings SHALL be reviewed whenever either side evolves.

Historical mappings SHALL remain reconstructable.


9. Imported Standards

Mappings SHOULD be used when integrating external standards such as:

  • Schema.org
  • OData CSDL
  • HL7 FHIR
  • O*NET
  • ESCO
  • BPMN
  • ArchiMate

Imported concepts SHALL retain their original identities.


10. Transformation

Some mappings MAY require semantic transformation.

Transformation rules SHALL be:

  • deterministic whenever practical;
  • documented;
  • traceable;
  • version-aware.

Transformation SHALL NOT silently alter semantic meaning.


11. Federation

Semantic Mapping is the preferred interoperability mechanism between heterogeneous Universes.

Federation participants SHOULD exchange canonical mappings before exchanging semantic knowledge.

Mappings SHALL support Projection exchange without requiring schema duplication.


12. Validation

A conforming implementation SHOULD validate:

  • source and target identities;
  • mapping type;
  • authority;
  • version compatibility;
  • semantic consistency;
  • traceability.

Mappings failing validation SHOULD NOT be used automatically.


13. Traceability

Every Mapping SHALL preserve:

  • provenance;
  • publishing authority;
  • publication Event;
  • version history;
  • related Contracts (when applicable).

Traceability SHALL survive federation.


14. Architectural Invariants

Every Semantic Mapping SHALL preserve:

  • canonical identities;
  • semantic sovereignty;
  • ownership;
  • provenance;
  • constitutional compliance.

Mappings SHALL connect meanings.

They SHALL NOT replace meanings.


15. Typical Examples

Examples include:

  • employee:Employee ↔ schema:Person (Extension)
  • employee:Skill ↔ O*NET Skill (Equivalent)
  • healthcare:Patient ↔ fhir:Patient (Equivalent)
  • organization:Department ↔ ArchiMate Business Actor (Partial Mapping)

These examples are informative rather than normative.

A worked interop appendix is in examples/interop/ — it imports Schema.org as a Semantic Package, maps a local employee.person to Schema.org, FHIR and FOAF, and projects the Object to RDF/OWL.


16. Future Directions

The Semantic Mapping Registry introduced in this document anticipates a full companion specification. That specification would define how registries are published, discovered and federated; how registry entries declare their canonical meaning, authority, version and confidence; how mappings are deprecated and superseded as standards evolve; and how a Federation of Registries lets participants cross-verify mappings without any single registry becoming a global semantic authority. The intent is a growing public commons of reusable mappings — O*NET, ESCO, HR-XML, Schema.org and beyond — so that interoperability is increasingly a matter of reference rather than negotiation.


Final Statement

Semantic Mapping is the interoperability bridge of the Meta-Universe.

Rather than forcing all participants to adopt a single vocabulary, Meta-Universe enables sovereign Universes to preserve their own semantic models while establishing explicit, traceable and version-aware correspondences between concepts. This allows knowledge to flow across heterogeneous ecosystems without sacrificing identity, meaning or constitutional autonomy.