Embedded Semantics Interoperability Architecture Report

Full report

On this page

Executive assessment and current-system interpretation

Architectural conclusion

Embedded Semantics should interoperate with the Semantic Web as a projection and exchange layer, not be rebuilt as an RDF-native ontology system.

The public architecture already contains the right separation of concerns. Embedded Semantics describes itself as a registry-backed multilingual semantic-identity system in which reviewed expressions resolve to a stable ConceptCode; model vectors are evidence rather than authority; the concept registry is authoritative; and concept definitions, expressions, relationships, model profiles, prototype evidence, and evaluation outcomes can evolve without rewriting ConceptCode identity.

That distinction should be preserved. The semantic-web stack is most valuable here when it gives Embedded Semantics:

• globally referenceable identifiers;
• standard vocabulary projection;
• multilingual label interchange;
• typed cross-graph mappings;
• provenance interoperability;
• graph validation;
• linked-data discovery;
• machine-readable public concept pages;
• optional graph querying.

It becomes harmful when RDF, OWL, inference, or third-party identifiers are allowed to determine what a ConceptCode means.

The recommended dependency direction is therefore:

                 Embedded Semantics authoritative layer
                 ======================================

    ConceptCode ──> governed Concept record
                       │
                       ├── definition
                       ├── reviewed expressions
                       ├── language/script metadata
                       ├── semantic relationships
                       ├── external mappings
                       ├── provenance
                       └── registry/version state
                               │
                               ▼
                    deterministic projections
                 ┌─────────────┼───────────────┐
                 ▼             ▼               ▼
               JSON         JSON-LD          RDF/SKOS
                                                 │
                              ┌──────────────────┼──────────────┐
                              ▼                  ▼              ▼
                            PROV-O             SHACL          DCAT
                              │
                              ▼
                    optional SPARQL replica

The arrow must not be reversed. An RDF store, ontology reasoner, Wikidata QID, or SKOS mapping must not become the allocator or ultimate arbiter of ConceptCode identity.

Findings from the public system

There is an important distinction between the published architectural intent and the currently deployed registry contents.

The public homepage describes reviewed multilingual expressions attached to one stable ConceptCode, gives semantic_registry.stable_concept_identity as an example, and says the intended output includes a human-readable concept page plus a stable JSON API representation.

As of August 23, 2026, however, the public status page reports zero published concepts, zero reviewed exact expressions, zero represented languages, and an inactive arbitrary-query semantic runtime. It says a governed prerelease bundle is expected to contain 11 concepts and 55 expressions but that those bootstrap records are absent from the deployed registry.

Accordingly, this report treats the public system as an architectural contract and prerelease public interface, not as evidence that a populated semantic knowledge graph is already operating. That matters because interoperability design can still be made cleanly now, before public identifiers and RDF modeling choices become difficult to reverse.

The existing public machine surface is already useful for this transition. The site advertises concept, status, resolver, registry-pack schema, bundle-manifest, and registry-pack endpoints, while explicitly saying that ConceptCode plus its registry definition are authoritative and expressions, embeddings, scores, prototypes, and model metadata are attached evidence.

The five semantic layers that must never be conflated

This distinction should be normative in the interoperability specification.

This division fits both Embedded Semantics and the standards. RDF itself is a graph data model, not a conceptual model; RDFS and OWL add increasingly strong formal entailment; SKOS intentionally represents concept schemes without requiring them to become formal ontologies.

Standards-value assessment

The strongest interoperability fit is:

JSON-LD is particularly aligned with Embedded Semantics because W3C explicitly designed JSON-LD as a way for existing JSON systems to gain Linked Data semantics with minimal changes, while remaining ordinary valid JSON usable without RDF knowledge.

The overall architectural answer is therefore:

ConceptCode first; HTTP IRI second; SKOS/JSON-LD/RDF as interoperable projections; PROV-O for traceability; SHACL for boundary validation; OWL and SPARQL only where their additional complexity is justified.

Identity architecture: ConceptCode, IRI, HTTP rules, and collision control

Should every ConceptCode have an IRI?

Yes. Every published ConceptCode should have exactly one canonical Embedded Semantics HTTPS IRI.

That does not mean the IRI replaces ConceptCode.

The two identifiers operate at different levels:

Compact application identifier:
semantic_registry.stable_concept_identity

Global Web identifier:
https://embeddedsemantics.com/entity/semantic_registry.stable_concept_identity

The first is ideal for:

• relational database keys;
• message payloads;
• API parameters;
• logs;
• caches;
• programming-language values;
• offline processing;
• compact AI-agent messages.

The second allows the same concept to participate in Linked Data, RDF graphs, JSON-LD, citations, external knowledge graphs, and dereferenceable Web identifiers.

Linked-data practice calls for URIs/IRIs as names for things, preferably HTTP identifiers that can be looked up to obtain useful descriptions and links to other identified resources. RDF also allows abstract concepts to be resources denoted by IRIs.

So the appropriate relationship is:

ConceptCode = authoritative local semantic identifier

canonical IRI = deterministic global Web projection of ConceptCode

not:

ConceptCode = abbreviated RDF URI

That difference is fundamental to remaining independent of the Semantic Web stack.

Should ConceptCodes remain valid compact identifiers without IRIs?

Absolutely. This should be a normative guarantee.

A conforming Embedded Semantics implementation should be able to perform:

expression -> ConceptCode
ConceptCode -> registry record
ConceptCode equality
ConceptCode storage
ConceptCode transmission

with no RDF library, IRI resolution, DNS query, HTTP request, JSON-LD context loading, graph database, or ontology engine.

The web IRI is an interoperability projection:

canonicalIRI(code) =
    "https://embeddedsemantics.com/entity/" + canonicalPathEncoding(code)

This creates a useful asymmetry:

ConceptCode  ─────deterministically─────>  canonical IRI
    ▲
    │
authoritative
    │
registry

IRI does NOT redefine ConceptCode

That architecture resembles successful entity systems in one useful respect: Wikidata has compact identifiers such as QIDs while also supplying persistent entity URIs and Linked Data representations. Wikidata's documentation explicitly distinguishes its persistent concept URI from the concrete data document describing the entity.

Embedded Semantics need not copy Wikidata's architecture, but the pattern demonstrates that compact identity and Web-global identity are complementary rather than mutually exclusive.

Proposed ConceptCode lexical rules

The public examples are lower-case, dot-separated codes such as semantic_registry.stable_concept_identity and mt.representation.machine_readable. The following should therefore be treated as a proposed future contract, not a claim about the undocumented current implementation:

^[a-z][a-z0-9_]*(?:\.[a-z][a-z0-9_]*)+$

Recommended invariants are:

That last rule is especially important. From:

semantic_registry.semantic_embedding
semantic_registry.semantic_residue

nothing should be inferred about broader/narrower, class membership, inheritance, or similarity merely because the strings share a prefix.

Proposed HTTP identifier architecture

I recommend three deliberately distinct resource families.

Canonical semantic identity:
https://embeddedsemantics.com/entity/{ConceptCode}

Human-readable descriptive document:
https://embeddedsemantics.com/concepts/{ConceptCode}

Application/API record:
https://embeddedsemantics.com/api/v1/concepts/{ConceptCode}

A fourth family can identify immutable record versions:

https://embeddedsemantics.com/record/{ConceptCode}/version/{RegistryVersion}

and a fifth can identify governed expressions where expression-level provenance is publicly exposed:

https://embeddedsemantics.com/expression/{ExpressionRecordId}

The distinction solves several problems simultaneously.

/entity/... means the concept.

/concepts/... means the Web page describing the concept.

/api/... means a particular representation/service record.

/record/.../version/... means a historical immutable registry-state artifact.

These should never accidentally acquire the same semantics through owl:sameAs.

Dereferencing rules

For the canonical identity IRI, the cleanest semantics are modeled after the identity/data distinction used by Wikidata: dereferencing the concept identifier leads clients to a representation of the concept rather than pretending the HTML page itself is the concept. Wikidata documents precisely this distinction for its concept URIs and entity-data URLs.

Recommended behavior:

GET /entity/semantic_registry.stable_concept_identity
Accept: text/html

303 See Other
Location: /concepts/semantic_registry.stable_concept_identity

GET /entity/semantic_registry.stable_concept_identity
Accept: application/ld+json

303 See Other
Location: /api/v1/concepts/semantic_registry.stable_concept_identity.jsonld

GET /entity/semantic_registry.stable_concept_identity
Accept: text/turtle

303 See Other
Location: /api/v1/concepts/semantic_registry.stable_concept_identity.ttl

A 303 architecture is not necessary for RDF to function; it is recommended here because Embedded Semantics makes semantic identity unusually central, so an explicit concept-versus-document boundary is worth the extra HTTP hop.

A simpler implementation could return negotiated 200 OK representations directly from /entity/{code}. HTTP explicitly supports content negotiation and representation-specific metadata. If operational simplicity outweighs the conceptual distinction, that is still interoperable. What should be avoided is exposing multiple apparently canonical identity URLs without stating their relationship.

Identifier persistence

The canonical entity IRI must inherit ConceptCode's stability semantics:

one ConceptCode
    =
one local concept identity
    =
one canonical Embedded Semantics entity IRI

Changing:

• a preferred label;
• a translation;
• a definition wording;
• a relationship;
• a mapping;
• a model profile;
• a vector;
• provenance;
• registry version

must not change either the ConceptCode or its canonical entity IRI if the underlying governed identity remains the same. This follows the project's own stated principle that those evidence and descriptive layers may change independently without rewriting ConceptCode identity.

Conversely, if semantic review concludes that two historically conflated concepts must be split, new ConceptCodes should be allocated rather than silently changing what the old identifier denotes.

Identity retirement and succession

A published ConceptCode should normally become deprecated, not deleted.

A retired entity should continue dereferencing and can say:

es:status es:Deprecated ;
dcterms:isReplacedBy <new-entity-iri> .

A split should not assert that the old concept is identical to all successors. A merge should distinguish:

historical identity
current preferred identity
semantic mapping

rather than pretending history never happened.

Dublin Core provides generic replacement and version relations suitable for record/document lifecycle metadata, while PROV-O provides explicit revision and derivation constructs for provenance histories.

Semantic-identity collision risks

There are several distinct collision classes.

Unicode deliberately permits visually confusable characters across scripts, making display spoofing a real concern for multilingual interfaces. This is an additional reason ConceptCode itself should remain ASCII even though expressions should remain Unicode-preserving.

Identity must not equal label equality

The public system already handles the crucial counterexample: exact-expression ambiguity can legitimately map one expression to more than one concept and should return ambiguous_expression rather than inventing a unique identity.

Therefore this rule should be normative:

same lexical form
≠ same ConceptCode
≠ skos:exactMatch
≠ owl:sameAs

Likewise:

same embedding neighborhood
≠ same ConceptCode

which directly follows the system's explicit separation of model evidence from authoritative semantic identity.

Semantic-web projection: SKOS, RDF, JSON-LD, schema.org, and the OWL boundary

SKOS should be the primary semantic-web vocabulary

Among the standards reviewed, SKOS is the best conceptual fit for Embedded Semantics.

SKOS is specifically designed for identifying and describing concepts, lexical labels, semantic relationships, concept schemes, and mappings to concepts in other schemes. Its specification explicitly distinguishes this use from a formal OWL knowledge representation system.

The baseline mapping should be:

How ConceptCode should map to skos:Concept

The IRI corresponding to the ConceptCode, rather than the ConceptCode string literal itself, should be the RDF subject:

<https://embeddedsemantics.com/entity/semantic_registry.stable_concept_identity>
    a skos:Concept ;
    dcterms:identifier "semantic_registry.stable_concept_identity" .

The string is the stable compact identifier.

The IRI is the globally linkable RDF resource.

The skos:Concept type says how that resource participates in a SKOS projection.

This is important because:

ConceptCode is not a skos:Concept.

The entity identified by ConceptCode
is represented in RDF as a skos:Concept.

That distinction keeps the application-level identity model independent.

Preferred and alternate labels

SKOS defines skos:prefLabel, skos:altLabel, and skos:hiddenLabel as lexical-label properties, with a critical integrity constraint: a resource may have no more than one skos:prefLabel for a given language tag. The properties are also mutually disjoint.

That creates one important interoperability question for Embedded Semantics.

Suppose the registry regards two reviewed English expressions as equally exact:

"stable concept identity"
"persistent concept identity"

That does not mean both should automatically become skos:prefLabel @en.

Instead, Embedded Semantics should distinguish:

semantic resolution status: reviewed exact expression
display label role: preferred / alternate

An expression may be semantically authorized for exact resolution while still being an skos:altLabel for display purposes.

This is a crucial modeling boundary because SKOS preference concerns lexical presentation, whereas Embedded Semantics exact-equivalence evidence concerns resolution to a stable concept identity.

Recommended rule:

For each ConceptCode + language/script profile:

0 or 1 display-preferred expression -> skos:prefLabel
all other governed lexical alternatives -> skos:altLabel

Expression-resolution authority remains in Embedded Semantics-specific metadata.

Multilingual expressions

Language-tagged RDF literals are a natural projection:

skos:prefLabel
    "Stable concept identity"@en ,
    "identidad conceptual estable"@es ,
    "安定した概念識別子"@ja ,
    "هوية مفهومية مستقرة"@ar .

Those four expressions appear on the project's own homepage as multilingual illustrations of the example ConceptCode.

SKOS explicitly supports language-tagged lexical labels and shows script-specific BCP 47 tags such as Japanese Han, Hiragana, Katakana and Latin-script variants. Therefore Embedded Semantics should preserve sufficiently specific language tags where script distinctions matter:

ja
ja-Hani
ja-Hira
ja-Kana
sr-Cyrl
sr-Latn
zh-Hans
zh-Hant

The authoritative registry should still retain whatever richer language metadata it requires. The RDF language tag is an interoperability projection, not necessarily the entire internal linguistic model.

Governed expressions should optionally be first-class resources

Plain SKOS labels are insufficient when an expression needs independent:

• review status;
• reviewer provenance;
• source;
• normalization record;
• evidence type;
• creation/review time;
• registry version;
• exact-resolution authorization;
• script metadata;
• validity period.

SKOS itself anticipates this problem. SKOS-XL permits labels to be represented as identifiable resources with a literal form and can “dumb down” those resources into normal SKOS labels.

There are therefore two sensible export profiles:

Simple profile:
Concept -> skos:prefLabel/altLabel -> literal

Governed profile:
Concept -> es:expression -> expression resource
                              ├── skosxl:literalForm
                              ├── language/script
                              ├── es:resolutionStatus
                              ├── es:reviewStatus
                              └── PROV-O metadata

I recommend not making SKOS-XL an internal dependency. Instead, let the native expression record remain authoritative and export it as either:

es:ReviewedExpression + skosxl:Label

or only the custom class if SKOS-XL's constraints do not fit the governing model.

Broader, narrower, and related relationships

For direct, asserted concept relationships:

es relation: broader  -> skos:broader
es relation: narrower -> skos:narrower
es relation: related  -> skos:related

SKOS defines broader/narrower as inverse hierarchical relations and supplies transitive superproperties for applications that want hierarchical closure; skos:related is associative and symmetric rather than transitive.

Embedded Semantics should preserve the distinction between:

asserted direct relationship
derived transitive relationship

For example:

A skos:broader B       # asserted registry edge
B skos:broader C       # asserted registry edge

A broaderTransitive C  # inference, not another asserted governance fact

Do not materialize the inferred edge into the authoritative Concept registry unless a reviewer independently asserts it.

And again:

mt.representation.machine_readable

must not become narrower than:

mt.representation

because the latter string happens to be a lexical prefix. String structure and conceptual hierarchy must remain separate.

RDF mapping

RDF should be treated as a loss-controlled graph serialization of registry meaning.

RDF's core data model consists of subject-predicate-object statements and can identify abstract concepts using IRIs. It does not require the source system itself to be an RDF database. SPARQL likewise can query RDF produced through middleware, not only data physically stored in a native RDF store.

That means an entirely legitimate Embedded Semantics implementation is:

native registry store
      │
      ├── native resolver
      ├── native JSON API
      │
      └── deterministic RDF projector
                  │
                  ├── JSON-LD
                  ├── Turtle
                  └── N-Quads/dump

There is no architectural requirement for Neo4j, Jena, RDF4J, GraphDB, Blazegraph, Virtuoso, or another graph/triplestore technology to become the system of record.

Minimal custom Embedded Semantics vocabulary

Avoid inventing properties for semantics that existing standards already express.

Reuse:

rdf:type
rdfs:label
skos:Concept
skos:ConceptScheme
skos:prefLabel
skos:altLabel
skos:definition
skos:broader
skos:narrower
skos:related
skos:exactMatch
skos:closeMatch
dcterms:identifier
dcterms:issued
dcterms:modified
prov:*
schema:termCode

Create es: properties only for Embedded Semantics-specific governance semantics, for example:

es:conceptCode
es:expression
es:resolutionStatus
es:reviewStatus
es:registryVersion
es:normalizedSearchForm
es:mappingAssertion
es:mappingStrength
es:confidenceEvidence
es:authorityStatus

Even es:conceptCode may be unnecessary if dcterms:identifier and schema:termCode are enough. A smaller custom vocabulary lowers the interoperability burden.

JSON-LD should be a first-class representation

Yes, public Concept pages should emit JSON-LD.

This is probably the single highest-value/lowest-cost semantic-web addition.

JSON-LD is a W3C Recommendation intended specifically to let existing JSON systems participate in Linked Data with minimal changes, while remaining directly usable by ordinary JSON software.

That matches Embedded Semantics almost perfectly.

A good implementation provides:

HTML page:
<script type="application/ld+json">...</script>

API:
Accept: application/json
    -> ordinary current API representation

API / entity representation:
Accept: application/ld+json
    -> semantically equivalent JSON-LD

A stronger option is to make the primary JSON response itself JSON-LD-compatible without compromising ordinary clients:

{
  "@context": "...",
  "@id": "...",
  "conceptCode": "...",
  "definition": {...},
  "expressions": [...]
}

A non-JSON-LD-aware client simply ignores @context and @id.

Illustrative JSON-LD representation

The following is a proposed representation, not a claim about a currently published Concept record. The ConceptCode and four sample expressions are taken from the homepage, but the live public registry presently reports zero published concepts.

{
  "@context": {
    "@version": 1.1,

    "skos": "http://www.w3.org/2004/02/skos/core#",
    "skosxl": "http://www.w3.org/2008/05/skos-xl#",
    "dcterms": "http://purl.org/dc/terms/",
    "prov": "http://www.w3.org/ns/prov#",
    "schema": "https://schema.org/",
    "es": "https://embeddedsemantics.com/vocab/",

    "conceptCode": "dcterms:identifier",
    "termCode": "schema:termCode",

    "prefLabel": {
      "@id": "skos:prefLabel",
      "@container": "@language"
    },
    "altLabel": {
      "@id": "skos:altLabel",
      "@container": "@language"
    },
    "definition": {
      "@id": "skos:definition",
      "@container": "@language"
    },

    "inScheme": {
      "@id": "skos:inScheme",
      "@type": "@id"
    },
    "broader": {
      "@id": "skos:broader",
      "@type": "@id"
    },
    "narrower": {
      "@id": "skos:narrower",
      "@type": "@id"
    },
    "related": {
      "@id": "skos:related",
      "@type": "@id"
    },

    "exactMatch": {
      "@id": "skos:exactMatch",
      "@type": "@id"
    },
    "closeMatch": {
      "@id": "skos:closeMatch",
      "@type": "@id"
    },

    "registryVersion": "es:registryVersion",
    "expressions": {
      "@id": "es:expression",
      "@container": "@set"
    },
    "literalForm": "skosxl:literalForm",
    "resolutionStatus": "es:resolutionStatus",
    "reviewStatus": "es:reviewStatus",

    "generatedAtTime": {
      "@id": "prov:generatedAtTime",
      "@type": "http://www.w3.org/2001/XMLSchema#dateTime"
    },
    "wasAttributedTo": {
      "@id": "prov:wasAttributedTo",
      "@type": "@id"
    }
  },

  "@id": "https://embeddedsemantics.com/entity/semantic_registry.stable_concept_identity",

  "@type": [
    "skos:Concept",
    "schema:DefinedTerm"
  ],

  "conceptCode": "semantic_registry.stable_concept_identity",
  "termCode": "semantic_registry.stable_concept_identity",

  "inScheme": "https://embeddedsemantics.com/scheme/core",

  "prefLabel": {
    "en": "Stable concept identity",
    "es": "identidad conceptual estable",
    "ja": "安定した概念識別子",
    "ar": "هوية مفهومية مستقرة"
  },

  "definition": {
    "en": "A stable governed semantic identity whose ConceptCode remains independent of language expressions and model-specific retrieval evidence."
  },

  "registryVersion": "example-version",

  "expressions": [
    {
      "@id": "https://embeddedsemantics.com/expression/example-en-1",
      "@type": [
        "es:ReviewedExpression",
        "skosxl:Label",
        "prov:Entity"
      ],
      "literalForm": {
        "@value": "Stable concept identity",
        "@language": "en"
      },
      "resolutionStatus": "reviewed_exact",
      "reviewStatus": "approved"
    },
    {
      "@id": "https://embeddedsemantics.com/expression/example-es-1",
      "@type": [
        "es:ReviewedExpression",
        "skosxl:Label",
        "prov:Entity"
      ],
      "literalForm": {
        "@value": "identidad conceptual estable",
        "@language": "es"
      },
      "resolutionStatus": "reviewed_exact",
      "reviewStatus": "approved"
    }
  ]
}

This representation deliberately exposes two different views of labels:

prefLabel
    -> convenient standardized SKOS view

expressions
    -> governed Embedded Semantics evidence records

That is preferable to trying to force all expression governance into SKOS literals.

Illustrative Turtle/RDF representation

@prefix es:      <https://embeddedsemantics.com/vocab/> .
@prefix concept: <https://embeddedsemantics.com/entity/> .
@prefix scheme:  <https://embeddedsemantics.com/scheme/> .
@prefix expr:    <https://embeddedsemantics.com/expression/> .

@prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .
@prefix skosxl:  <http://www.w3.org/2008/05/skos-xl#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix prov:    <http://www.w3.org/ns/prov#> .
@prefix schema:  <https://schema.org/> .

scheme:core
    a skos:ConceptScheme ;
    skos:prefLabel "Embedded Semantics Core Registry"@en .

concept:semantic_registry.stable_concept_identity
    a skos:Concept, schema:DefinedTerm ;

    dcterms:identifier
        "semantic_registry.stable_concept_identity" ;

    schema:termCode
        "semantic_registry.stable_concept_identity" ;

    skos:inScheme scheme:core ;

    skos:prefLabel
        "Stable concept identity"@en ,
        "identidad conceptual estable"@es ,
        "安定した概念識別子"@ja ,
        "هوية مفهومية مستقرة"@ar ;

    skos:definition
        "A stable governed semantic identity whose ConceptCode remains independent of language expressions and model-specific retrieval evidence."@en ;

    es:expression
        expr:example-en-1 ,
        expr:example-es-1 .

expr:example-en-1
    a es:ReviewedExpression, skosxl:Label, prov:Entity ;
    skosxl:literalForm "Stable concept identity"@en ;
    es:resolutionStatus "reviewed_exact" ;
    es:reviewStatus "approved" .

expr:example-es-1
    a es:ReviewedExpression, skosxl:Label, prov:Entity ;
    skosxl:literalForm "identidad conceptual estable"@es ;
    es:resolutionStatus "reviewed_exact" ;
    es:reviewStatus "approved" .

Illustrative SKOS vocabulary representation

The following uses deliberately hypothetical concepts to demonstrate vocabulary structure rather than asserting undocumented relationships in today's registry:

@prefix concept: <https://embeddedsemantics.com/entity/> .
@prefix scheme:  <https://embeddedsemantics.com/scheme/> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

scheme:example
    a skos:ConceptScheme ;
    skos:prefLabel "Example Embedded Semantics Scheme"@en .

concept:example.transport
    a skos:Concept ;
    skos:inScheme scheme:example ;
    dcterms:identifier "example.transport" ;
    skos:prefLabel "Transport"@en .

concept:example.rail_transport
    a skos:Concept ;
    skos:inScheme scheme:example ;
    dcterms:identifier "example.rail_transport" ;
    skos:prefLabel "Rail transport"@en ;
    skos:broader concept:example.transport .

concept:example.rail_station
    a skos:Concept ;
    skos:inScheme scheme:example ;
    dcterms:identifier "example.rail_station" ;
    skos:prefLabel "Railway station"@en ;
    skos:related concept:example.rail_transport .

The deliberate mismatch between the ConceptCode strings and hierarchy illustrates a core rule: hierarchy is represented by governed graph relationships, never derived from ConceptCode namespace syntax.

schema.org relationship

schema.org should be used for discoverability and Web integration, not to replace SKOS.

schema:DefinedTerm is specifically intended for words, phrases, acronyms or similar terms that have formal definitions; it provides termCode, description, name, and inDefinedTermSet.

Therefore concept pages can safely dual-type:

concept:foo
    a skos:Concept, schema:DefinedTerm ;
    schema:termCode "foo" ;
    schema:inDefinedTermSet scheme:core .

A useful conceptual division is:

SKOS:
vocabulary and knowledge-organization interoperability

schema.org:
general-purpose Web/search/agent discoverability

Do not force nuanced multilingual mapping semantics into schema.org.

And be particularly conservative with schema:sameAs. Schema.org describes it as a URL that unambiguously indicates the item's identity. It is therefore unsuitable as the default representation of merely similar external ontology concepts.

RDFS boundary

RDFS is useful for documenting the small Embedded Semantics export vocabulary:

es:ReviewedExpression
    a rdfs:Class ;
    rdfs:label "Reviewed expression"@en .

es:expression
    a rdf:Property ;
    rdfs:label "expression"@en .

RDFS provides class, property, subclass, subproperty, label, comment, domain, and range semantics and can generate additional type entailments.

That makes aggressive use of rdfs:domain and rdfs:range potentially surprising. For example:

es:expression rdfs:domain skos:Concept .

does not merely “validate” that subjects ought to be SKOS Concepts; under RDFS semantics it can cause subjects using that predicate to be inferred to be skos:Concept.

Therefore:

Use SHACL for data constraints. Use RDFS domain/range only when the inferred type is genuinely intended.

OWL boundary

OWL should not be the primary conceptual model for Embedded Semantics.

OWL 2 is a formal ontology language with defined semantics for classes, properties, individuals, data values, equality, restrictions and logical consequences. That is valuable when Embedded Semantics intentionally publishes a formal domain ontology, but it is stronger than what is needed to express “stable concept identity plus governed multilingual lexical evidence.”

Most ConceptCodes should therefore be:

a skos:Concept

not automatically:

a owl:Class

A concept scheme answers:

“What governed idea does this identifier represent?”

An OWL class typically participates in assertions about membership and formal class semantics:

“Which individuals belong to this class, and what follows logically from that?”

Those are not the same question.

SKOS explicitly notes that concepts can coexist with OWL representations but that SKOS itself is not a formal knowledge-representation language.

If a particular Embedded Semantics ConceptCode genuinely also denotes a formal ontology class, dual typing can be made intentionally:

concept:some_formal_category
    a skos:Concept, owl:Class .

But it should require explicit governance rather than being generated for every record.

owl:sameAs should be exceptional

This is one of the strongest recommendations in the report.

OWL's SameIndividual semantics means the two names denote equal individuals and can be substituted for one another without changing ontology meaning; its RDF form is owl:sameAs.

SKOS explicitly warns that owl:sameAs is generally inappropriate for cross-scheme concept mapping and shows how unwanted entailments can result; it intentionally supplies skos:exactMatch and skos:closeMatch with weaker information-retrieval-oriented semantics.

Therefore:

external semantic correspondence
    -> SKOS mapping property

true co-reference with full substitution semantics
    -> possibly owl:sameAs

The latter should require an explicit, high-bar governance decision.

RDF-star / RDF 1.2 boundary

As of August 23, 2026, RDF 1.2 Concepts is on the W3C Recommendation track as a Candidate Recommendation Snapshot and introduces triple terms; the August 12 RDF 1.2 Turtle document is still a Working Draft and adds triple/reification annotation syntax.

This makes the RDF 1.2 statement-annotation model attractive for provenance such as:

Concept A skos:exactMatch External B

reviewed by Alice
on date X
based on evidence Y
with registry version Z

but it should not yet be a minimum interoperability dependency.

For the minimum layer, use normal RDF 1.1-compatible mapping resources:

:map-123
    a es:MappingAssertion, prov:Entity ;
    es:subject concept:a ;
    es:predicate skos:exactMatch ;
    es:object <external-iri> ;
    prov:wasAttributedTo :reviewer ;
    prov:generatedAtTime "2026-08-23T00:00:00Z"^^xsd:dateTime .

Optionally also emit the convenient direct triple:

concept:a skos:exactMatch <external-iri> .

Once RDF 1.2 reaches sufficient standard and tooling maturity, the richer annotation syntax can become an additional serialization profile without changing the registry model.

Governance and provenance: SHACL, PROV-O, Dublin Core, DCAT, and ActivityStreams

SHACL should validate the projection, not own the registry

The public site advertises a reviewed-registry-pack JSON Schema endpoint. That existing architectural direction is sensible: if the native registry is JSON-oriented, its native schema/validator should remain authoritative.

SHACL should add a semantic interoperability validation layer.

SHACL 1.0 is a W3C Recommendation specifically designed to validate RDF graphs against graph-based conditions. As of August 2026, SHACL 1.2 Core is still a Working Draft, so interoperability-critical validation should target the stable 1.0 feature set unless a specific newer feature is worth accepting as experimental.

The pipeline becomes:

Registry pack
     │
     ├── native JSON/schema validation        [authoritative]
     │
     ▼
RDF projection
     │
     └── SHACL validation                     [interop contract]

A SHACL failure should normally mean:

“The exported graph violates the Embedded Semantics RDF profile.”

It should not automatically mean:

“The underlying ConceptCode ceases to exist.”

SHACL validation opportunities

A Concept shape can enforce:

@prefix sh:      <http://www.w3.org/ns/shacl#> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix es:      <https://embeddedsemantics.com/vocab/> .

es:ConceptShape
    a sh:NodeShape ;
    sh:targetClass skos:Concept ;

    sh:nodeKind sh:IRI ;

    sh:property [
        sh:path dcterms:identifier ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:datatype <http://www.w3.org/2001/XMLSchema#string> ;
        sh:pattern "^[a-z][a-z0-9_]*(\\.[a-z][a-z0-9_]*)+$"
    ] ;

    sh:property [
        sh:path skos:inScheme ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:nodeKind sh:IRI
    ] ;

    sh:property [
        sh:path skos:prefLabel ;
        sh:uniqueLang true
    ] .

Useful constraints include:

SHACL's sh:uniqueLang directly supports enforcing language uniqueness on labels, including the “one preferred label per language” SKOS requirement. The current SHACL 1.2 draft retains this functionality, although the stable interoperability baseline should still be SHACL 1.0.

More complex constraints—such as acyclic governed hierarchy or comparing a ConceptCode to the tail of its canonical IRI—may require SHACL-SPARQL or native validation logic rather than forcing all governance into SHACL.

PROV-O is an excellent fit for the existing provenance philosophy

PROV-O models provenance through entities, activities, and agents and provides relations such as prov:used, prov:wasGeneratedBy, prov:wasAttributedTo, prov:wasDerivedFrom, prov:wasRevisionOf, prov:specializationOf, and generation times.

That lines up strongly with Embedded Semantics' public statement that definitions, expressions, renderings, relationships, model profiles, prototype evidence, and evaluation outcomes should be independently traceable without rewriting ConceptCode identity.

The key modeling decision is:

Apply provenance primarily to registry records, assertions, mappings, expressions and versions—not to semantic identity as though a concept itself were merely a document generated by a workflow.

For example:

Stable concept identity:
entity/foo

Registry snapshot v7:
record/foo/version/7

Review activity:
activity/review-123

Reviewer:
agent/alice

Then:

<record/foo/version/7>
    a prov:Entity ;
    prov:specializationOf <record/foo> ;
    prov:wasRevisionOf <record/foo/version/6> ;
    prov:wasGeneratedBy <activity/review-123> ;
    prov:generatedAtTime "2026-08-23T14:00:00Z"^^xsd:dateTime .

<activity/review-123>
    a prov:Activity ;
    prov:wasAssociatedWith <agent/alice> .

PROV-O explicitly supports revisions, specialization, attribution, generation, use, and provenance bundles.

Provenance of reviewed expressions

A strong model is:

expression record
     │
     ├── literal
     ├── language
     ├── role
     ├── resolution status
     └── provenance
             │
             ├── review activity
             ├── reviewer/organization
             ├── evidence source
             └── generated-at/version

In PROV-O:

expr:e123
    a es:ReviewedExpression, prov:Entity ;
    skosxl:literalForm "example"@en ;
    prov:wasGeneratedBy activity:review-e123 ;
    prov:generatedAtTime "2026-08-23T15:00:00Z"^^xsd:dateTime .

activity:review-e123
    a prov:Activity ;
    prov:used source:s456 ;
    prov:wasAssociatedWith agent:reviewer-17 .

This is preferable to attaching reviewer metadata to the entire Concept simply because one expression was reviewed.

Provenance of mappings

Cross-graph mappings deserve especially strong provenance because external ontologies evolve.

A mapping record should contain at least:

local ConceptCode
external authority
external identifier
external canonical IRI
mapping relation
review status
reviewer or reviewing organization
review date
source revision/version if available
evidence
mapping lifecycle state

Representing the mapping itself as a provenance-bearing resource solves a major limitation of a bare:

concept:a skos:exactMatch wd:Q123 .

A consumer can still receive that simple triple, while expert consumers can inspect why it was asserted.

Dublin Core relationship

Dublin Core Terms should provide generic metadata rather than semantic identity logic.

DCMI maintains a general metadata vocabulary including identifier, description, issued/modified dates, version/relation terms, and conformsTo.

Useful mappings include:

dcterms:identifier
dcterms:title
dcterms:description
dcterms:language
dcterms:issued
dcterms:modified
dcterms:publisher
dcterms:license
dcterms:conformsTo
dcterms:isVersionOf
dcterms:hasVersion
dcterms:replaces
dcterms:isReplacedBy

Use them primarily for:

• registry releases;
• record versions;
• distribution documents;
• concept scheme metadata;
• API representation metadata.

For the ConceptCode itself:

dcterms:identifier "semantic_registry.stable_concept_identity"

is a good generic interoperability statement.

DCAT relationship

DCAT should describe the registry as a dataset and its published distributions, not individual concepts.

DCAT 3 is a W3C Recommendation intended to describe datasets and data services in interoperable catalogs and facilitate decentralized/federated data discovery.

For example:

Embedded Semantics Registry Release
    a dcat:Dataset

Distributions:
    JSON registry pack
    JSON-LD dump
    Turtle dump
    N-Quads dump

This makes a release discoverable without making DCAT part of concept resolution.

A release representation might say:

:registry-2026-08
    a dcat:Dataset ;
    dcterms:title "Embedded Semantics Registry"@en ;
    dcterms:issued "2026-08-23"^^xsd:date ;
    dcterms:conformsTo :embedded-semantics-rdf-profile ;
    dcat:distribution
        :json-distribution,
        :jsonld-distribution,
        :turtle-distribution .

The registry should continue to work if no DCAT consumer ever sees this metadata.

ActivityStreams relationship

ActivityStreams 2.0 is a W3C Recommendation for representing potential and completed activities in JSON.

It is not needed for Concept identity.

It could, however, provide a lightweight subscription/change feed such as:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Update",
  "actor": "https://embeddedsemantics.com/agent/registry",
  "object": "https://embeddedsemantics.com/entity/example.concept",
  "published": "2026-08-23T18:00:00Z"
}

Useful consumers would include:

• downstream caches;
• indexing services;
• AI agents maintaining local mirrors;
• ontology bridge services;
• registry synchronization pipelines.

PROV-O and ActivityStreams should remain distinct:

PROV-O:
Why/how/by whom did this state arise?

ActivityStreams:
What happened recently that subscribers may want to react to?

The former is provenance. The latter is notification/event interchange.

External graph linkage, equivalence rules, and the semantic-identity bridge

Equivalence must not be treated as identity

This is the most important cross-knowledge-graph principle.

Embedded Semantics should define a mapping ladder such as:

SKOS itself defines exactMatch as a high-confidence relation supporting interchangeability across a wide range of information-retrieval applications and closeMatch as a weaker relation suitable for some such applications. exactMatch is transitive and symmetric; closeMatch is symmetric but not transitive.

This has an important consequence:

skos:exactMatch is already stronger than many teams intuitively assume.

If:

A exactMatch B
B exactMatch C

SKOS semantics entail:

A exactMatch C

whereas close mappings do not have that transitive behavior.

Therefore Embedded Semantics should not use skos:exactMatch merely because:

• labels are translations;
• embeddings are close;
• one source says “same as” informally;
• both entities map to the same third-party resource;
• a model produces high similarity.

The registry should maintain its own reviewed mapping state even if the RDF projection uses SKOS.

Proposed equivalence decision procedure

An exact_mapping should require reviewers to compare at least:

definition/intension
scope
broader/narrower boundaries
known exclusions
temporal meaning
jurisdiction/domain
entity-versus-class interpretation
granularity
external source version

A reasonable governing question is:

“Would substituting one concept for the other in ordinary information retrieval, indexing, terminology alignment, and entity linking preserve the intended concept often enough to justify SKOS exact equivalence?”

If the answer is “mostly, but not in all important contexts,” use closeMatch.

If one concept's scope contains the other, use a directional broad/narrow mapping.

If they are only topical neighbors, use relatedMatch.

Hard prohibition on label-based equivalence

The following should never independently create an exact mapping:

label equality
case-folded label equality
translation equality
same external description
vector cosine similarity
same model cluster
same Wikipedia title
same search result
shared parent concept
ConceptCode lexical similarity

That position is directly aligned with Embedded Semantics' existing principle that semantic candidate evidence is not semantic identity and that ambiguous or unsupported resolution should abstain.

Wikidata linkage strategy

Wikidata should be treated as an external authority and mapping target, not an upstream identity allocator.

Wikidata entities have stable IDs such as QIDs and corresponding persistent concept URIs; its Linked Data interface supplies format-negotiated entity descriptions and a SPARQL service.

An Embedded Semantics mapping record should therefore look conceptually like:

{
  "conceptCode": "example.some_concept",
  "externalScheme": "wikidata",
  "externalIdentifier": "Q12345",
  "externalIri": "http://www.wikidata.org/entity/Q12345",
  "relation": "closeMatch",
  "reviewStatus": "approved",
  "reviewedAt": "2026-08-23"
}

and project to:

concept:example.some_concept
    skos:closeMatch <http://www.wikidata.org/entity/Q12345> .

The mapping is intentionally not:

ConceptCode := Q12345

nor, by default:

concept:example.some_concept
    owl:sameAs <http://www.wikidata.org/entity/Q12345> .

The reason is not that Wikidata is unreliable. It is that independent registries may legitimately:

• choose different concept boundaries;
• represent different levels of abstraction;
• split one other's entities;
• merge entities differently;
• evolve independently;
• carry different governance guarantees.

External ontology identifier strategy

Every external reference should be stored as a structured mapping rather than an untyped alternate ID.

Good:

authority:     wikidata
identifier:    Q12345
iri:           ...
relation:      closeMatch
reviewed:      true
evidence:      ...

Poor:

externalIds: ["Q12345", "C0012345", "123456"]

because identifier strings are meaningless without an authority namespace.

Likewise, do not put all mappings into generic:

sameAs

or:

relatedTo

The relation itself is semantic information.

External IDs must never replace ConceptCode

Suppose an Embedded Semantics concept maps to:

Wikidata Q123
External Ontology A: X-44
External Ontology B: 9271

The internal model should remain:

                   Wikidata Q123
                      ▲
                      │ exact/close
                      │
Ontology X-44 ◄──── ConceptCode ─────► Ontology B:9271
                 authoritative pivot

not:

ConceptCode = Wikidata ID = Ontology A ID = Ontology B ID

This is exactly where Embedded Semantics can add unique value.

Can Embedded Semantics become a semantic-identity bridge?

Yes—this is arguably one of its strongest potential roles.

But it should operate as a governed hub of mappings, not a global identity-merging engine.

Consider:

KG A: A:4711
      │
      │ closeMatch
      ▼
ES: finance.bank_as_financial_institution
      ▲
      │ exactMatch
      │
KG B: B:193
      │
      │ narrowerMatch
      ▼
KG C: C:banking_organization

Applications can ask:

“What does registry A call the Embedded Semantics concept?”

or:

“What are the closest corresponding entities in registries B and C?”

without asserting:

A:4711 = B:193 = C:banking_organization

This “semantic pivot” architecture is safer than pairwise identity flattening.

It also provides a compact ordinary-software identifier:

finance.bank_as_financial_institution

without requiring an application to adopt any one external KG.

Bridge mappings should be evidence-bearing

A mapping bridge becomes trustworthy only if consumers can inspect:

who asserted the mapping?
when?
against which version?
what relation strength?
what evidence?
was it human-reviewed?
was it model-suggested?
is it current?

That aligns naturally with the project's existing evidence-vs-authority philosophy.

A model may propose:

possible closeMatch -> Q123
score -> 0.94

but a published governed mapping becomes:

reviewed closeMatch -> Q123

The model score remains provenance/evidence, not the mapping relation's semantic definition.

Mapping inference must be explicitly bounded

Suppose:

ES:A skos:exactMatch KG1:B
KG1:B skos:exactMatch KG2:C

A SKOS-aware reasoner can derive ES:A skos:exactMatch KG2:C because exactMatch is transitive.

That is legitimate SKOS inference, but Embedded Semantics should not automatically promote the derived mapping into its governed registry.

Represent:

asserted graph:
A exactMatch B
B exactMatch C

inferred graph:
A exactMatch C

and keep those graph states distinct.

This is the explicit equivalence-versus-inference boundary requested in the brief.

Recommended mapping confidence model

Do not encode semantic relation and confidence as the same variable.

For example:

relation = closeMatch
confidence = high

is perfectly meaningful.

So is:

relation = exactMatch
reviewStatus = provisional

during review.

The properties answer different questions:

mapping relation:
What semantic relation is being claimed?

confidence:
How strong is the evidence?

review state:
Has governance authorized publication?

provenance:
Who/what produced the evidence and claim?

Combining them into a single floating-point score would recreate exactly the evidence/identity conflation Embedded Semantics is designed to avoid.

Delivery, linked data, SPARQL, performance, and security

Public Concept pages should emit JSON-LD

Yes. Strong recommendation.

Every concept page should place a compact JSON-LD description in HTML:

<script type="application/ld+json">
{
  "@context": "...",
  "@id": "https://embeddedsemantics.com/entity/example.concept",
  "@type": ["skos:Concept", "schema:DefinedTerm"],
  "conceptCode": "example.concept"
}
</script>

This makes concept pages useful simultaneously to:

• browsers;
• ordinary Web applications;
• search/indexing systems;
• Linked Data consumers;
• AI agents;
• knowledge-graph importers.

JSON-LD's design explicitly targets integration into existing Web/JSON systems without requiring ordinary JSON consumers to understand RDF.

RDF content negotiation

Yes, RDF representations should be content-negotiated, but with explicit file-format URLs as a convenience.

Recommended media-type matrix:

RDF/XML should not be implemented merely because it historically exists. Turtle and JSON-LD cover most contemporary interoperability needs while preserving readability and JSON friendliness.

HTTP content negotiation is a standard mechanism for selecting among representations, and Wikidata demonstrates a mature entity-data model that combines persistent concept URIs with negotiation and explicit format suffixes.

Useful explicit URLs would be:

/api/v1/concepts/{code}.json
/api/v1/concepts/{code}.jsonld
/api/v1/concepts/{code}.ttl
/api/v1/concepts/{code}.nt

That is valuable for:

• debugging;
• static linking;
• caches;
• command-line clients;
• systems that cannot conveniently set Accept.

Avoid language negotiation changing semantic identity

Machine representations should normally contain all governed languages rather than returning different graph identities depending on Accept-Language.

For example:

Accept: application/ld+json

should receive all approved labels unless the API explicitly supports a “localized view” profile.

HTML UI language may vary, but:

entity IRI
ConceptCode
underlying concept graph

must remain unchanged.

This prevents caches and clients from mistaking a localized presentation for a different semantic entity.

HTTP caching

Published concept representations are excellent caching targets.

Recommended response mechanisms include:

ETag
Last-Modified
Cache-Control
Vary: Accept

HTTP explicitly supports validators and negotiated representations, allowing efficient revalidation of cached content.

Because ConceptCodes are stable but records can evolve, a strong pattern is:

canonical identity IRI:
stable forever

current representation:
cacheable, revalidatable

version representation:
immutable, long-lived cache

The public status page already exposes a deterministic bundle SHA-256, indicating that content-addressable release integrity is compatible with the project's existing deployment model.

Static registry dumps before SPARQL

Before operating a SPARQL endpoint, publish periodic deterministic exports:

registry.json
registry.jsonld
registry.ttl
registry.nq

with:

• release/version ID;
• generation timestamp;
• hash;
• license;
• schema/profile version;
• provenance metadata.

DCAT can describe these as distributions.

For many knowledge-graph integrators this is simpler, cheaper, more reproducible, and easier to cache than querying a live endpoint.

What a SPARQL endpoint would add

SPARQL is a W3C RDF query language that supports graph-pattern queries, optional patterns, aggregation, subqueries, filtering, source graphs, and RDF-graph results across diverse RDF sources.

For Embedded Semantics it would enable queries such as:

SELECT ?concept ?label ?wikidata
WHERE {
  ?concept a skos:Concept ;
           skos:prefLabel ?label ;
           skos:exactMatch ?wikidata .

  FILTER(LANG(?label) = "es")
  FILTER(STRSTARTS(STR(?wikidata), "http://www.wikidata.org/entity/"))
}

High-value use cases include:

SPARQL federation's SERVICE mechanism can merge results from distributed SPARQL endpoints. That could make Embedded Semantics particularly effective as a semantic bridge.

What complexity a SPARQL endpoint introduces

The cost is real.

A public endpoint creates another operational product with:

RDF projection synchronization
query engine
dataset/version semantics
named-graph policy
reasoning policy
result limits
query timeouts
resource governance
abuse protection
endpoint monitoring
availability expectations
security hardening
documentation

It also raises a semantic question:

“When a SPARQL result differs from the native registry because of projection lag or inference, which is authoritative?”

The answer must remain:

native governed registry is authoritative
SPARQL is a queryable projection

SPARQL security is nontrivial

The W3C SPARQL Protocol specification explicitly warns that under-constrained or complex queries can consume large amounts of CPU, storage, bandwidth, and other resources and become denial-of-service vectors. It also notes that services retrieving external resources on behalf of clients can effectively become proxies for attacks against third parties, and recommends restrictions, query limits, and the option of omitting updates.

A public Embedded Semantics endpoint should therefore initially be:

read-only
replica-backed
no SPARQL Update
bounded execution time
bounded rows
bounded memory
rate-limited
restricted federation/SERVICE
restricted remote graph loading
query logging

Federated SERVICE should probably be disabled or allowlisted on the public endpoint even if federation is enabled internally.

Recommendation on SPARQL

Do not make SPARQL part of the minimum interoperability layer.

Recommended progression:

native API
    ↓
JSON-LD/Turtle per-concept representations
    ↓
static RDF dump
    ↓
internal SPARQL for QA
    ↓
read-only public SPARQL if real demand emerges

This captures most interoperability value before accepting the largest operational burden.

Performance implications of RDF/JSON-LD

Per-concept RDF generation should be inexpensive because the authoritative record is small and deterministic. The best implementation is usually to generate RDF/JSON-LD at publication time or cache generated representations rather than rebuilding graph structures for every request.

Potential costs are:

JSON-LD documents can be processed as ordinary JSON, but full Linked Data processing can require context handling and graph transformation; W3C also documents streaming approaches for very large JSON-LD datasets.

Keep asserted and inferred graphs separate

A mature RDF distribution should use named graphs such as:

/graph/asserted
/graph/provenance
/graph/mappings
/graph/inferred/skos

Default consumers should receive asserted registry semantics.

An inferred graph can materialize:

skos:broaderTransitive
skos:exactMatch closure
selected RDFS entailments

but should identify its entailment profile and generation version.

This separation guarantees that:

assertion ≠ inference

and prevents a downstream reasoner from making derived graph state appear to be human-governed registry truth.

JSON-LD remote-context security

JSON-LD remote contexts can cause processors to dereference remote resources, and the W3C processing specification explicitly defines that dereferencing behavior. W3C also notes privacy implications when third-party context servers can observe usage.

For Embedded Semantics:

Publication:
host a versioned ES context on embeddedsemantics.com

Ingestion:
do not blindly dereference arbitrary third-party @context URLs

Use:

• context allowlists;
• local context caches;
• pinned known contexts;
• network timeouts;
• payload-size limits;
• no unrestricted internal-network fetches.

Most importantly, the production resolver should not need JSON-LD context retrieval to resolve a ConceptCode.

Multilingual-expression security

Because expressions are intentionally Unicode-preserving, interfaces must account for:

• visually confusable characters;
• bidi behavior;
• control characters;
• mixed-script spoofing;
• normalization inconsistencies;
• HTML/script injection.

Unicode's security guidance documents visually confusable strings and bidi-related spoofing risks.

Recommended distinction:

originalExpression:
exact governed Unicode sequence

normalizedLookupKey:
explicitly specified resolution/search normalization

displayRendering:
escaped safe text

ConceptCode:
ASCII invariant

Never silently overwrite the original governed expression with a normalized version.

Web application security

Labels and definitions must be treated as data, never trusted HTML.

Concept pages should:

HTML-escape lexical content
sanitize any explicitly allowed markup
apply Content Security Policy
use correct Content-Type
use JSON serializers rather than string concatenation

External mapping IRIs should be validated and, where security-sensitive fetching occurs, checked against scheme/host/network policies. An RDF import operation must never imply permission to fetch arbitrary internal or file-system resources.

Provenance privacy

A detailed provenance graph can unintentionally expose:

• reviewer names;
• email addresses;
• internal workflow IDs;
• unpublished sources;
• moderation discussions.

Therefore define public and internal provenance profiles.

For example:

public:
prov:wasAttributedTo organization/review-board
review date
source publication
mapping state

internal:
individual reviewer
audit log
workflow comments
internal evidence URLs

PROV-O makes provenance exchange possible; it does not require every provenance fact to be public.

Recommended minimum layer, roadmap, and anti-patterns

Recommended minimum interoperability layer

The first production interoperability profile should be deliberately small.

Core identity contract. ConceptCode remains the mandatory canonical compact application identifier. Every published ConceptCode receives one deterministic canonical HTTPS entity IRI. Neither requires RDF processing to function.

ConceptCode
    ↕ deterministic
canonical HTTPS entity IRI

SKOS projection. Every published concept projects as:

skos:Concept
skos:inScheme
skos:prefLabel / altLabel
skos:definition
skos:broader / narrower / related
SKOS mapping properties

SKOS was designed precisely for concept schemes, lexical labels, semantic relationships, and cross-scheme mappings without requiring full formal ontology semantics.

JSON-LD projection. Add an @id and stable versioned context to the concept JSON or offer a semantically equivalent JSON-LD variant. Embed JSON-LD in every public concept page. JSON-LD is intentionally compatible with ordinary JSON workflows.

Turtle representation. Offer per-concept Turtle and a registry Turtle/N-Quads dump. RDF is an exchange graph, not the authoritative persistence requirement.

PROV-O. Use it for expression-review provenance, mapping provenance, registry-record versions, publishing activities, and provenance bundles. Keep the stable concept identity distinct from a changing record version.

SHACL 1.0. Publish an ES RDF profile plus SHACL shapes that test the generated graph. Preserve native JSON/schema validation as the authoritative registry validator. SHACL is explicitly designed for RDF graph validation.

schema.org. Dual-type concept-page entities as schema:DefinedTerm and expose schema:termCode, name, description, and inDefinedTermSet as appropriate.

Dublin Core and DCAT. Use Dublin Core for generic release/record metadata and DCAT for downloadable registry releases and distributions.

The resulting minimum stack is:

AUTHORITATIVE
    ConceptCode
    native registry record
    native resolver rules
    native governance
         │
         ▼
INTEROPERABILITY
    HTTPS IRI
    JSON-LD
    SKOS/RDF
    PROV-O
    SHACL
    schema.org
    Dublin Core / DCAT

No OWL reasoner and no SPARQL server are required.

Recommended conformance profiles

It would be useful to define several explicit profiles rather than saying vaguely that Embedded Semantics “supports RDF.”

ES-Core
    ConceptCode + native registry semantics

ES-Web
    canonical HTTPS IRI + human page + JSON API

ES-LinkedData
    JSON-LD + Turtle + SKOS + DCTerms

ES-Governance
    expression resources + PROV-O + mapping assertions

ES-Dataset
    registry dumps + DCAT

ES-Query
    optional SPARQL service

ES-RDF12
    future RDF 1.2 statement annotation profile

A consumer can then support the layer it actually needs.

Advanced interoperability roadmap

A practical progression is:

Because RDF 1.2 and its Turtle annotation syntax remain on the standards track rather than being a fully settled minimum baseline as of August 2026, this last step should remain optional for now.

Likewise, SHACL 1.2 is still a Working Draft, so the minimum conformance profile should remain compatible with stable SHACL 1.0.

Standards that should remain deliberately optional

OWL. Adopt only where a domain requires formal class/property axioms and the inference consequences are explicitly intended. Do not make ordinary ConceptCodes OWL classes by default.

Public SPARQL. Add once the mapping graph and user demand are large enough to justify the operational/security cost. SPARQL adds powerful standardized querying but also explicit resource-exhaustion and proxying risks.

RDF 1.2 annotations. Excellent future fit for evidence-bearing relationship statements, but use stable RDF-compatible mapping entities as the current interchange baseline.

ActivityStreams. Useful for change notifications, unnecessary for semantic identity.

Anti-patterns to avoid

Making the IRI the only identifier.

Bad:
application DB stores only long Semantic-Web URLs

Better:
ConceptCode is compact application identity;
IRI is deterministic global projection.

This would unnecessarily make ordinary applications dependent on Web/RDF conventions.

Making RDF the authoritative registry.

RDF should faithfully serialize the registry. The registry should not need a triple store to decide whether an expression is approved.

Turning every Concept into an OWL class.

A governed idea is not automatically a logical class with a meaningful extension. SKOS was specifically designed to avoid forcing concept schemes into that formal-ontology role.

Using owl:sameAs for semantic similarity.

OWL equality is substitutive identity; SKOS specifically warns that it can produce undesirable consequences when used to align concept schemes.

Treating skos:exactMatch as harmless metadata.

It is transitive and symmetric. Use it only when its semantics are intended.

Inferring Concept identity from a label.

The project itself recognizes exact-expression ambiguity and abstains rather than forcing unique identity.

Inferring identity from embeddings.

The public architecture explicitly says vectors and scores are evidence, not semantic authority.

Using skos:prefLabel to mean “authorized exact resolver expression.”

SKOS allows only one preferred label per language, whereas an Embedded Semantics concept may plausibly have several reviewed lexical realizations. Preserve separate resolution-governance metadata.

Encoding semantic hierarchy in ConceptCode syntax.

Namespaces should organize identifiers, not generate broader/narrower statements.

Replacing ConceptCodes with Wikidata QIDs or other ontology IDs.

That sacrifices local governance and makes the registry's identity semantics dependent on another authority.

Flattening all external identifiers into a generic externalIds array.

Always store authority, local identifier, canonical IRI, mapping relation, evidence, and provenance.

Letting inferred triples enter the authoritative graph silently.

Maintain explicit asserted-versus-inferred graph boundaries.

Requiring remote JSON-LD context fetches for core runtime behavior.

JSON-LD processors can dereference remote contexts; interoperability metadata should never become a dependency of the exact production resolver.

Launching unrestricted public SPARQL Update.

The standards themselves identify denial-of-service and externally mediated request risks; a public ES endpoint should begin read-only and resource-bounded.

Deleting retired identifiers.

Persistence matters more than a cosmetically clean active vocabulary. Keep tombstone/deprecated descriptions and explicit successor metadata.

Final architectural position

The conceptual stack should ultimately look like this:

┌──────────────────────────────────────────────────────────┐
│                  IDENTITY / AUTHORITY                    │
│                                                          │
│  ConceptCode                                             │
│  semantic_registry.stable_concept_identity               │
│                                                          │
│  Governed definition + registry lifecycle                │
└──────────────────────────┬───────────────────────────────┘
                           │
            deterministic │ global projection
                           ▼
┌──────────────────────────────────────────────────────────┐
│                    WEB IDENTITY                          │
│                                                          │
│  canonical HTTPS entity IRI                             │
└──────────────────────────┬───────────────────────────────┘
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
       JSON API          JSON-LD        RDF/SKOS
                                            │
                     ┌──────────────────────┼─────────────┐
                     ▼                      ▼             ▼
                  PROV-O                  SHACL       schema.org
                     │                                    │
                     ▼                                    ▼
               audit/history                         discovery
                     │
                     ▼
              external mappings
          ┌──────────┼───────────┐
          ▼          ▼           ▼
      Wikidata    Ontology A   KG B
          \          |          /
           \         |         /
            \        |        /
             └─ governed bridge ┘

In this architecture:

IDENTITY
    is ConceptCode + its governed concept record.

LABELS
    are multilingual lexical expressions attached to identity.

EQUIVALENCE
    is an explicit reviewed relation between independent identities.

RELATIONSHIPS
    connect concepts without merging them.

INFERENCE
    derives additional graph statements under a declared reasoning regime.

None of those five layers should be allowed to masquerade as another.

That produces a system that is more interoperable than a closed registry without becoming more ontologically complicated than its problem requires.

RDF supplies a universal graph interchange model. SKOS supplies the right conceptual vocabulary. JSON-LD brings that model into ordinary APIs with minimal friction. PROV-O expresses the traceability Embedded Semantics already considers foundational. SHACL makes the export contract testable. schema.org improves Web discoverability. DCAT and Dublin Core make releases discoverable and describable. Wikidata and other knowledge graphs become mapped peers. SPARQL becomes an optional advanced query surface. OWL remains available where actual formal inference is needed rather than being imposed globally.

Most importantly, the architecture preserves the distinctive proposition already visible in the public system: semantic identity should be stable, governed, usable by ordinary software, and independent of probabilistic representations that may change beneath it.

Bibliography

Embedded Semantics — public architecture and current deployment. The project homepage defines the registry-backed identity model, stable ConceptCodes, multilingual expressions, vector/evidence separation, and intended human/JSON output surface. The current status page documents the live deployment boundary and prerelease bundle state. The research methodology explains abstention, semantic-resolution goals, hard negatives, and independent provenance. The FAQ documents exact-expression resolution, ambiguity, and model-versus-authority distinctions. The machine-readable project description lists the public endpoints and states the semantic-authority rule.

RDF. W3C, RDF 1.2 Concepts and Abstract Data Model, Candidate Recommendation Snapshot, April 2026. It defines RDF's graph model, IRIs/literals/blank nodes/triple terms, resources, statements, entailment regimes, and the RDF 1.2 work.

RDF 1.2 Turtle and statement annotation. W3C, RDF 1.2 Turtle, Working Draft, August 12, 2026. It describes triple terms, reification-oriented constructs, and the new annotation syntax; its Working Draft status is the reason this report keeps those capabilities out of the minimum interoperability profile.

RDF Schema. W3C, RDF Schema 1.1. It defines RDF classes, properties, labels, comments, domains, ranges, subclasses, and subproperties and their associated inference semantics.

SKOS. W3C, SKOS Simple Knowledge Organization System Reference. This is the principal source for skos:Concept, concept schemes, lexical labels, semantic relations, mapping properties, and SKOS-XL. The lexical-label constraints—including the single preferred label per language and SKOS-XL behavior—are particularly important to the Embedded Semantics mapping. Its mapping rules define exact/close/broad/narrow/related mapping semantics and exact-match transitivity. Its explicit comparison with owl:sameAs supports the recommendation not to collapse independent semantic registries into OWL identity.

JSON-LD. W3C, JSON-LD 1.1. JSON-LD is a W3C Recommendation providing an RDF/Linked Data interpretation of ordinary JSON and is specifically designed as a low-friction upgrade path for existing Web and JSON systems. W3C's processing specification documents remote-context dereferencing behavior relevant to secure import implementations.

OWL. W3C, OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax. OWL provides formally defined ontology semantics for classes, properties and individuals. Its individual-equality semantics establish that owl:sameAs means genuine substitutable identity rather than approximate semantic correspondence.

SHACL. W3C, Shapes Constraint Language (SHACL), Recommendation. It defines RDF graph validation against shapes and constraints. W3C, SHACL 1.2 Core, Working Draft, August 2026, documents the emerging successor but remains work in progress as of the date of this report.

PROV-O. W3C, PROV-O: The PROV Ontology. It provides the Entity/Activity/Agent model and relations for generation, use, attribution, derivation, revision, specialization, provenance bundles and related history.

SPARQL. W3C, SPARQL 1.1 Query Language. It defines standard graph querying across RDF datasets and RDF views. W3C, SPARQL 1.1 Federated Query, defines the SERVICE mechanism for distributed queries. W3C, SPARQL 1.1 Protocol, documents denial-of-service, external retrieval/proxy, resource-limit, and update-security considerations relevant to any public endpoint.

Dublin Core. Dublin Core Metadata Initiative, DCMI Metadata Terms. It supplies reusable generic metadata for identifiers, titles/descriptions, dates, versions, conformity, and resource relationships.

DCAT. W3C, Data Catalog Vocabulary — Version 3, Recommendation, August 2024. It defines interoperable metadata for datasets, catalogs, distributions and data services and is appropriate for registry release publication rather than concept identity.

schema.org. Schema.org, DefinedTerm. It defines Web-oriented structured-data properties including termCode, name, description, identifier, and inDefinedTermSet, making it a useful discoverability projection for Concept pages. Schema.org's sameAs documentation explicitly describes unambiguous item identity, supporting conservative use for Embedded Semantics mappings.

Wikidata. Wikidata, Data access. It documents persistent entity/concept identifiers, entity-data representations, HTTP redirection/content negotiation, explicit RDF/JSON-LD formats, revisions, and the Wikidata Query Service.

ActivityStreams. W3C, Activity Streams 2.0, Recommendation. It defines a JSON model for activities and is therefore relevant to optional registry-update feeds rather than the core concept model.

Linked Data principles. Tim Berners-Lee, W3C, Linked Data — Design Issues. It articulates the use of URIs as names, HTTP URIs that can be looked up, useful returned descriptions, and links to other identified things.

HTTP semantics. IETF, RFC 9110: HTTP Semantics. It specifies content negotiation, representation metadata, validators, and caching mechanisms underpinning the proposed HTTP representation architecture.

Unicode security. Unicode Consortium, Unicode Security Considerations. It documents visually confusable Unicode sequences and related spoofing concerns that matter for a Unicode-preserving multilingual expression registry.