Ontology-based Semantic Interaction for Internet of Agents
draft-zhang-dmsc-ioa-semantic-interaction-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Lianhua Zhang , Yun Li , Huiling Yang , Shoufeng Wang | ||
| Last updated | 2026-10-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhang-dmsc-ioa-semantic-interaction-03
Network Working Group L. Zhang
Internet-Draft Y. Li
Intended status: Standards Track H. Yang
Expires: 22 April 2027 S. Wang
AsiaInfo Technologies (China) Inc.
19 October 2026
Ontology-based Semantic Interaction for Internet of Agents
draft-zhang-dmsc-ioa-semantic-interaction-03
Abstract
This document specifies an ontology-based semantic profile for
expressing capabilities, intents, tasks, and domain context in agent
interactions. It defines a core vocabulary, a JSON-LD serialization
profile, and processing rules for determining semantic compatibility
using explicit identifiers, applicable constraints, and accepted
alignment artifacts. It distinguishes descriptive metadata and
candidate mapping suggestions from semantic values used in decisions.
The profile can be carried by existing discovery and interaction
mechanisms; it does not define an authorization, transport, session,
or directory synchronization protocol. Deterministic processing is
limited to the declared profile, versions, constraints, and accepted
mappings, and does not imply automatic interpretation of arbitrary
natural-language content.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires 22 April 2027 [Page 1]
Internet-Draft Semantic Interaction for IoA October 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 5
4. Semantic Layer Architecture . . . . . . . . . . . . . . . . . 6
5. Ontology Model (Normative) . . . . . . . . . . . . . . . . . 7
5.1. Core Classes . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Core Properties . . . . . . . . . . . . . . . . . . . . . 7
5.3. Profiles and Versions . . . . . . . . . . . . . . . . . . 8
5.4. Constraints and Consistency Rules . . . . . . . . . . . . 9
5.5. Vocabulary and Domain Fragments . . . . . . . . . . . . . 9
6. JSON-LD Serialization Profile (Normative) . . . . . . . . . . 11
6.1. Context Requirements . . . . . . . . . . . . . . . . . . 11
6.2. Message Semantic Envelope . . . . . . . . . . . . . . . . 13
6.3. Capability Registration Payload . . . . . . . . . . . . . 15
6.4. Decision-Sensitive Semantic Processing . . . . . . . . . 15
6.5. Migration from Earlier Draft Examples . . . . . . . . . . 16
7. Semantic Negotiation and Alignment . . . . . . . . . . . . . 16
7.1. Compatibility Determination . . . . . . . . . . . . . . . 16
7.2. Alignment Artifacts . . . . . . . . . . . . . . . . . . . 17
7.3. Conflict Resolution Rules . . . . . . . . . . . . . . . . 18
7.4. Candidate Mapping Generation . . . . . . . . . . . . . . 18
8. Discovery and Capability Semantics . . . . . . . . . . . . . 19
9. Interaction Semantics . . . . . . . . . . . . . . . . . . . . 19
10. Relationship to A2A . . . . . . . . . . . . . . . . . . . . . 20
11. Relationship to Directory, Mediation, and Other Protocol
Work . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12. Example Flows . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Cross-Domain Candidate and Accepted Mapping . . . . . . 21
12.2. A2A Extension Advertisement Fragment . . . . . . . . . . 21
12.3. Interaction and Domain Validation . . . . . . . . . . . 22
12.4. Alignment Artifact Example . . . . . . . . . . . . . . . 22
12.5. Processing Outcome Examples . . . . . . . . . . . . . . 23
12.6. Illustrative NLIP-Style Carriage . . . . . . . . . . . . 24
13. Compliance Requirements . . . . . . . . . . . . . . . . . . . 24
14. Security Considerations . . . . . . . . . . . . . . . . . . . 24
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
Zhang, et al. Expires 22 April 2027 [Page 2]
Internet-Draft Semantic Interaction for IoA October 2026
17. Normative References . . . . . . . . . . . . . . . . . . . . 25
18. Informative References . . . . . . . . . . . . . . . . . . . 26
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27
A.1. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction
The Internet of Agents (IoA) envisions large-scale collaboration
among heterogeneous agents across domains, vendors, and execution
environments. Current agent ecosystems often fail to interoperate
because capability descriptions, task intents, and context semantics
are expressed using incompatible vocabularies. This semantic
mismatch blocks cross-domain discovery, reliable task decomposition,
and predictable coordination.
This document defines an ontology-based semantic layer for agent
interaction. The layer provides:
* A minimal ontology model for capabilities, intents, tasks, and
context.
* A JSON-LD serialization profile (RECOMMENDED) for exchange over
existing interaction protocols, with allowance for other RDF
serializations.
* A negotiation and alignment procedure for heterogeneous
ontologies.
Existing agent protocols such as A2A already define useful
application-layer objects and discovery hooks, including agent cards,
skills, messages, tasks, artifacts, and extension points. However,
those mechanisms do not by themselves define a common ontology,
ontology version comparison rules, alignment artifacts, or
deterministic semantic compatibility procedures across domains. This
document fills that gap while remaining reusable by such protocols.
The semantic layer complements existing interaction and discovery
protocols. Deterministic processing is limited to explicit
identifiers, declared versions, required constraints, and accepted
mappings. Candidate generation and natural-language interpretation
do not establish decision-sensitive semantic compatibility.
This revision distinguishes candidate mapping generation from
validated compatibility, and completed incompatibility from a check
that could not be completed. Semantic compatibility remains separate
from authorization and execution admission.
Zhang, et al. Expires 22 April 2027 [Page 3]
Internet-Draft Semantic Interaction for IoA October 2026
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119] and [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are used in this document:
Internet of Agents (IoA): An ecosystem and architecture enabling
interoperable collaboration among heterogeneous agents across domains
and environments.
Semantic Layer: A logical layer that standardizes meaning
representation for agent interaction, independent of transport.
Ontology: A formal vocabulary of concepts and relations that can be
used to describe capabilities, intents, tasks, and context.
Semantic Profile: A minimal, structured set of fields used to express
interaction semantics.
Capability: A well-defined function or service that an agent can
provide, described semantically.
Intent: A goal-oriented statement describing the desired outcome of
an interaction.
Task: A unit of work with a lifecycle and status, linked to intent
and capability.
Context: Constraints, assumptions, and environmental conditions
relevant to a task or interaction.
Alignment: A mapping procedure between ontologies to reconcile
equivalent or related concepts.
Descriptive metadata provides labels, explanations, examples, or
other information intended to assist interpretation. A decision-
sensitive semantic value is a value whose interpretation affects
routing, execution, task acceptance, or another policy-controlled
decision. A candidate mapping is a proposed relationship between
semantic terms. An accepted alignment artifact is a mapping whose
identity, applicability, and provenance have been validated and whose
use is permitted by the receiver's policy.
Zhang, et al. Expires 22 April 2027 [Page 4]
Internet-Draft Semantic Interaction for IoA October 2026
Carrier binding: Rules that associate a semantic profile with an
existing interaction protocol, including its messages, task or
operation identifiers, negotiation, and security context. This
document specifies requirements on such bindings but not a universal
binding protocol.
In this document, a canonical identifier is an identifier in the form
prescribed by the applicable profile, after only the deterministic
expansion or normalization that the profile expressly defines. It
does not imply heuristic equivalence between distinct IRIs.
3. Scope and Non-Goals
This document specifies:
* A normative semantic ontology model.
* A JSON-LD serialization profile (RECOMMENDED) for interaction and
discovery semantics, with allowance for other RDF serializations.
* A negotiation procedure for semantic compatibility.
* Alignment artifacts and conflict resolution rules.
This document does not specify:
* Transport, session, or security protocols.
* Task lifecycle, message framing, streaming, or artifact delivery
behavior.
* A specific discovery or registration protocol.
* Registry lifecycle management, federation consistency, or
discovery ranking policies.
* A full ontology library for a specific industry domain.
The requirements apply to deployments that negotiate or advertise
this semantic profile. They do not require every agent or every
application protocol to implement an ontology layer. A capability
advertisement is not required to include a task-specific intent.
Zhang, et al. Expires 22 April 2027 [Page 5]
Internet-Draft Semantic Interaction for IoA October 2026
4. Semantic Layer Architecture
The semantic layer sits above interaction protocols and below
application logic. It provides a structured meaning representation
that can be exchanged, validated, and mapped across heterogeneous
agents. The semantic layer is protocol-agnostic and can be carried
by existing agent-to-agent interaction mechanisms.
The layer enables:
* Capability alignment across different vocabularies.
* Intent clarity for task decomposition and coordination.
* Context sharing for constraints and assumptions.
For example, an A2A deployment can carry this semantic layer using
A2A agent-card extension declarations and task or message metadata,
while continuing to use the native A2A task, message, artifact, and
streaming procedures defined by that protocol [A2A-SPEC].
For cross-domain deployments, a shared semantic knowledge base (e.g.,
ontology and concept registries with version history) MAY be used as
a common reference to improve semantic consistency.
The semantic layer is illustrated in Figure 1.
+------------------------------+
| Application Logic |
+------------------------------+
| Semantic Layer (this doc) |
+------------------------------+
| Interaction Protocols |
+------------------------------+
| Transport / Security |
+------------------------------+
Figure 1
Figure 1: Semantic Layer Position
The protocol-suite architecture in [MACP] provides one deployment
context. Gateway directories maintain versions, lifecycle state,
provenance and visibility; gateway mediation can consume those
records and the semantic compatibility result as inputs to a separate
decision [DIRECTORY] [MEDIATION].
Zhang, et al. Expires 22 April 2027 [Page 6]
Internet-Draft Semantic Interaction for IoA October 2026
5. Ontology Model (Normative)
Implementations MUST interpret the vocabulary and baseline field
meanings defined in this section. Support means interpreting the
terms where applicable, not including every term in every payload.
RDF supplies the underlying graph model [RDF11-CONCEPTS]; RDFS
supplies the class and property vocabulary [RDF-SCHEMA]. OWL MAY be
used for domain extensions [OWL2-OVERVIEW].
This revision uses the provisional vocabulary namespace
https://example.org/ioa/semantic# (prefix ioa). It identifies the
vocabulary defined here and does not require dereferencing that URL.
The namespace is provisional pending specification development.
Implementations MUST NOT assume that a different namespace, including
one used in an earlier draft example, is an alias without an accepted
mapping.
5.1. Core Classes
* ioa:Agent: an entity that provides capabilities and participates
in tasks.
* ioa:Capability: a function or service, with applicable input/
output constraints.
* ioa:Intent: a declared goal, with the capabilities and conditions
needed to realize it.
* ioa:Task: a unit of work associated with intent and context;
lifecycle behavior remains defined by the carrier.
* ioa:Context: domain and other explicitly modeled interpretation
conditions.
* ioa:SemanticProfile: a declaration of semantic references and
interpretation context.
ioa:Message is an optional graph projection of a carrier message for
the hasProfile relationship; it does not define message framing.
ioa:Domain, ioa:Concept, and ioa:TermBinding support domain
declarations and term disambiguation. Domain extensions MAY define
Skill, Resource, or Constraint classes.
5.2. Core Properties
* hasCapability: Agent to Capability; providedBy: Capability to
Agent.
Zhang, et al. Expires 22 April 2027 [Page 7]
Internet-Draft Semantic Interaction for IoA October 2026
* hasIntent: Task to Intent; hasContext: Task to Context.
* requiresCapability: Task or Intent to Capability. This property
does not assert that an Intent is a Task.
* hasProfile: a carrier message projection to SemanticProfile.
* ontologyId: one ontology IRI; ontologyVersion: one non-empty
version string.
* capabilityRefs: one or more Capability IRIs; intentRef: one Intent
IRI in a task-specific semantic envelope.
* profileVersion: an explicit profile-instance revision string when
supplied; alignmentRef: an alignment artifact IRI; profileContext:
a Context node.
* domain: a Domain IRI on Context; termBindings: TermBinding nodes;
term: a non-empty literal; sense: a Concept IRI.
* inDomain: a Concept to Domain relation; appliesToDomain: an Intent
to Domain relation.
* abbr and preferredAbbr: descriptive literal labels on concepts;
label: a descriptive rdfs:label.
* inputs and outputs: input/output media-type literals on
Capability. Media type equality alone does not establish
equivalence of all capability constraints.
* sourceLang and targetLang: language-code literals interpreted
under the applicable domain profile.
These names are in the ioa namespace except label, which abbreviates
rdfs:label in the JSON-LD context. The source and target roles above
describe permitted use; they are not an instruction to infer missing
types as a substitute for input validation. Additional required
domain constraints MUST be defined by the applicable domain profile.
5.3. Profiles and Versions
The baseline task-specific SemanticProfile contains one ontologyId,
one non-empty ontologyVersion, one or more capabilityRefs, and one
intentRef. profileContext, alignmentRef, an instance identifier, and
profileVersion are optional. Capability-only advertisements follow
the separate requirements in Section 6.3; they need not invent an
intent for a task that does not yet exist.
Zhang, et al. Expires 22 April 2027 [Page 8]
Internet-Draft Semantic Interaction for IoA October 2026
Ontology and profile versions are explicit identifiers, not an
implicit semantic-version ordering. Equality of ontology IDs or a
shared major version does not by itself establish semantic
compatibility. A domain profile permitting cross-version use MUST
specify the applicable relationship and constraints. Receivers MUST
NOT infer such a relationship from the version strings alone.
A reused profile MUST be associated with an unambiguous accepted
revision, either by an immutable reference, a profileVersion combined
with an instance identifier, or an equivalent carrier-binding
mechanism. Changing the accepted interpretation requires
revalidation as specified in Section 9.
5.4. Constraints and Consistency Rules
Receivers MUST validate baseline field presence, cardinality, types,
and identifier expansion before relying on a semantic envelope. They
MUST also evaluate the required constraints of the accepted domain
profile. A field with the wrong type is invalid; an unavailable
required external constraint leaves the compatibility check
Indeterminate rather than proving incompatibility.
RDF/OWL inference is not a substitute for closed-set field
validation. RDFS domain and range can imply types; they do not by
themselves reject a missing field or an out-of-range parameter.
SHACL MAY be used to express additional validation rules [SHACL].
An intent MUST be applicable to the declared capabilities under the
accepted profile. If a profile declares a domain restriction, a term
binding MUST satisfy that restriction. Cross-domain bindings MAY be
valid where explicitly permitted by the domain profile; the mere
presence of more than one domain is not an error.
5.5. Vocabulary and Domain Fragments
The following Turtle fragments define the baseline class/property
terms and illustrate domain concepts. They do not define an
authorization model or all domain validation constraints.
Zhang, et al. Expires 22 April 2027 [Page 9]
Internet-Draft Semantic Interaction for IoA October 2026
@prefix ioa: <https://example.org/ioa/semantic#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
ioa:Agent a rdfs:Class .
ioa:Capability a rdfs:Class .
ioa:Intent a rdfs:Class .
ioa:Task a rdfs:Class .
ioa:Context a rdfs:Class .
ioa:SemanticProfile a rdfs:Class .
ioa:Message a rdfs:Class .
ioa:Domain a rdfs:Class .
ioa:Concept a rdfs:Class .
ioa:TermBinding a rdfs:Class .
ioa:hasCapability a rdf:Property .
ioa:providedBy a rdf:Property .
ioa:hasIntent a rdf:Property .
ioa:hasContext a rdf:Property .
ioa:requiresCapability a rdf:Property .
ioa:hasProfile a rdf:Property .
ioa:ontologyId a rdf:Property .
ioa:ontologyVersion a rdf:Property .
ioa:capabilityRefs a rdf:Property .
ioa:intentRef a rdf:Property .
ioa:profileVersion a rdf:Property .
ioa:alignmentRef a rdf:Property .
ioa:profileContext a rdf:Property .
ioa:domain a rdf:Property .
ioa:termBindings a rdf:Property .
ioa:term a rdf:Property .
ioa:sense a rdf:Property .
ioa:inDomain a rdf:Property .
ioa:appliesToDomain a rdf:Property .
ioa:abbr a rdf:Property .
ioa:preferredAbbr a rdf:Property .
ioa:inputs a rdf:Property .
ioa:outputs a rdf:Property .
ioa:sourceLang a rdf:Property .
ioa:targetLang a rdf:Property .
Zhang, et al. Expires 22 April 2027 [Page 10]
Internet-Draft Semantic Interaction for IoA October 2026
@prefix ioa: <https://example.org/ioa/semantic#> .
@prefix cs: <https://example.org/onto/cs#> .
@prefix law: <https://example.org/onto/law#> .
cs:ComputerScience a ioa:Domain .
cs:LargeLanguageModel a ioa:Concept ;
ioa:inDomain cs:ComputerScience ; ioa:abbr "LLM" .
cs:TechTranslation a ioa:Capability .
cs:TranslateTechDoc a ioa:Intent ;
ioa:requiresCapability cs:TechTranslation ;
ioa:appliesToDomain cs:ComputerScience .
law:Law a ioa:Domain .
law:MasterOfLaws a ioa:Concept ;
ioa:inDomain law:Law ; ioa:preferredAbbr "LL.M." .
6. JSON-LD Serialization Profile (Normative)
JSON-LD 1.1 is the RECOMMENDED serialization [JSON-LD].
Implementations claiming the JSON-LD role MUST produce and parse the
baseline context and envelopes in this section. Another
representation MAY be negotiated by a carrier binding only if it
defines equivalent identifiers, types, required fields, and
validation behavior. RDF encodings do not remove the processing
requirements in this document.
6.1. Context Requirements
The following inline context defines baseline term expansion. The
keys @id and @type are used directly; no implicit alias named id or
type is defined. IRI-valued references MUST expand to absolute IRIs.
Profiles SHOULD use this inline context to avoid a mandatory network
fetch. A domain extension can add its own prefixes, but MUST NOT
redefine the protected core terms.
{
"@context": {
"@version": 1.1,
"@protected": true,
"ioa": "https://example.org/ioa/semantic#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"ontologyId": {
"@id": "ioa:ontologyId",
"@type": "@id"
},
"capabilityRefs": {
"@id": "ioa:capabilityRefs",
"@type": "@id",
"@container": "@set"
Zhang, et al. Expires 22 April 2027 [Page 11]
Internet-Draft Semantic Interaction for IoA October 2026
},
"intentRef": {
"@id": "ioa:intentRef",
"@type": "@id"
},
"alignmentRef": {
"@id": "ioa:alignmentRef",
"@type": "@id"
},
"domain": {
"@id": "ioa:domain",
"@type": "@id"
},
"sense": {
"@id": "ioa:sense",
"@type": "@id"
},
"hasCapability": {
"@id": "ioa:hasCapability",
"@type": "@id"
},
"providedBy": {
"@id": "ioa:providedBy",
"@type": "@id"
},
"hasIntent": {
"@id": "ioa:hasIntent",
"@type": "@id"
},
"hasContext": {
"@id": "ioa:hasContext",
"@type": "@id"
},
"requiresCapability": {
"@id": "ioa:requiresCapability",
"@type": "@id"
},
"hasProfile": {
"@id": "ioa:hasProfile",
"@type": "@id"
},
"inDomain": {
"@id": "ioa:inDomain",
"@type": "@id"
},
"appliesToDomain": {
"@id": "ioa:appliesToDomain",
"@type": "@id"
Zhang, et al. Expires 22 April 2027 [Page 12]
Internet-Draft Semantic Interaction for IoA October 2026
},
"ontologyVersion": "ioa:ontologyVersion",
"profileVersion": "ioa:profileVersion",
"profileContext": "ioa:profileContext",
"termBindings": "ioa:termBindings",
"term": "ioa:term",
"inputs": "ioa:inputs",
"outputs": "ioa:outputs",
"sourceLang": "ioa:sourceLang",
"targetLang": "ioa:targetLang",
"abbr": "ioa:abbr",
"preferredAbbr": "ioa:preferredAbbr",
"label": "rdfs:label"
}
}
A sender MAY include only the definitions needed for the terms it
uses, provided that every used term has exactly the baseline meaning
and required type handling. Unmapped decision-sensitive terms MUST
NOT be silently dropped during JSON-LD expansion. Unknown
descriptive extension terms MAY be ignored only where the domain
profile permits that treatment.
A binding permitting remote contexts or alignment/profile references
MUST define trusted retrieval sources, retrieval time and size
budgets, maximum reference depth, cycle and redirect handling, and a
way to identify the accepted resource revision. Policy-prohibited
retrieval, timeout, and missing required resources MUST NOT become
false compatibility or absence claims. Fetches MUST be constrained
to prevent server-side request forgery and resource exhaustion.
6.2. Message Semantic Envelope
A task-specific envelope MUST contain @context, @type identifying
ioa:SemanticProfile, exactly one ontologyId IRI, exactly one non-
empty ontologyVersion string, a non-empty capabilityRefs array of
IRIs, and exactly one intentRef IRI. Identifiers and version values
are interpreted with Section 5.3 and the domain profile. Optional
fields MUST satisfy their declared types when present.
{
"@context": {
"@version": 1.1,
"@protected": true,
"ioa": "https://example.org/ioa/semantic#",
"ontologyId": {
"@id": "ioa:ontologyId",
"@type": "@id"
Zhang, et al. Expires 22 April 2027 [Page 13]
Internet-Draft Semantic Interaction for IoA October 2026
},
"capabilityRefs": {
"@id": "ioa:capabilityRefs",
"@type": "@id",
"@container": "@set"
},
"intentRef": {
"@id": "ioa:intentRef",
"@type": "@id"
},
"domain": {
"@id": "ioa:domain",
"@type": "@id"
},
"sense": {
"@id": "ioa:sense",
"@type": "@id"
},
"ontologyVersion": "ioa:ontologyVersion",
"profileContext": "ioa:profileContext",
"termBindings": "ioa:termBindings",
"term": "ioa:term",
"cs": "https://example.org/onto/cs#"
},
"@type": "ioa:SemanticProfile",
"ontologyId": "https://example.org/onto/agent-core",
"ontologyVersion": "1.0",
"capabilityRefs": [
"cs:TechTranslation"
],
"intentRef": "cs:TranslateTechDoc",
"profileContext": {
"@type": "ioa:Context",
"domain": "cs:ComputerScience",
"termBindings": [
{
"@type": "ioa:TermBinding",
"term": "LLM",
"sense": "cs:LargeLanguageModel"
}
]
}
}
Zhang, et al. Expires 22 April 2027 [Page 14]
Internet-Draft Semantic Interaction for IoA October 2026
6.3. Capability Registration Payload
A capability-only advertisement MUST identify each Capability and
declare its input/output constraints under an identified domain
profile. It is not a task-specific semantic envelope and does not
require intentRef. Registration transport and directory admission
remain outside this specification. The following is a capability
fragment, not a complete registration protocol message.
{
"@context": {
"@version": 1.1,
"@protected": true,
"ioa": "https://example.org/ioa/semantic#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"inputs": "ioa:inputs",
"outputs": "ioa:outputs",
"label": "rdfs:label",
"cs": "https://example.org/onto/cs#"
},
"@id": "cs:TechTranslation",
"@type": "ioa:Capability",
"label": "Technical Document Translation",
"inputs": [
"text/plain"
],
"outputs": [
"text/plain"
]
}
6.4. Decision-Sensitive Semantic Processing
Senders MUST represent decision-sensitive references to capabilities,
intents, and other semantic concepts using the identifier forms
defined by the applicable profile. Labels and free-form natural-
language or model-generated text MAY accompany those references as
descriptive metadata, but MUST NOT replace the required identifiers.
Parameter values MUST use the types, units, and comparison rules
defined by the applicable profile; this requirement does not require
numeric or other literal values to be encoded as identifiers.
Zhang, et al. Expires 22 April 2027 [Page 15]
Internet-Draft Semantic Interaction for IoA October 2026
Receivers MUST validate decision-sensitive values against the
applicable profile, ontology version, required constraints, and
accepted alignment artifacts before relying on semantic
compatibility. Normal parsing and identifier expansion explicitly
defined by the serialization profile are permitted. Receivers MUST
NOT repair ambiguous or non-conformant decision-sensitive input by
guessing identifiers, inferring aliases from labels, or applying
heuristic semantic substitutions.
Malformed or ambiguous input MUST NOT be used as an established
semantic basis for a decision. The receiver MUST reject the affected
semantic processing, request correction or renegotiation, or exclude
the affected values from decision-sensitive use. Exclusion MUST NOT
silently remove a required constraint or enable an operation that
depends on the excluded value.
6.5. Migration from Earlier Draft Examples
Earlier examples used an undeclared remote context and keys such as
type and id. This revision supplies explicit term definitions and
uses @type and @id directly. The example namespace also changes to
the provisional example.org namespace defined in Section 5. Old
field spellings and namespaces MUST NOT be assumed to have the new
meanings without an explicitly defined mapping or negotiated
encoding.
A deployment migrating an earlier payload SHOULD emit a corrected
envelope with the intended expanded identifiers and explicit version
information. Compatibility with a prior interpretation MUST be
established under Section 7.1 rather than inferred from the Internet-
Draft revision number. This document does not claim wire
compatibility with the incomplete earlier examples.
7. Semantic Negotiation and Alignment
A carrier binding MUST define how supported profiles are advertised,
how a proposed profile or mapping is identified, how acceptance or
correction is communicated, and how the accepted revision is
associated with the operation. The following requirements specify
semantic outcomes; they do not define a universal negotiation message
format.
7.1. Compatibility Determination
Semantic compatibility processing MUST distinguish the following
outcomes:
Zhang, et al. Expires 22 April 2027 [Page 16]
Internet-Draft Semantic Interaction for IoA October 2026
* Compatible: all required semantic references and constraints have
been validated for the requested use, either directly or through
an accepted alignment artifact.
* Incompatible: processing completed and established a conflict with
at least one required semantic condition.
* Indeterminate: processing could not establish whether all required
semantic conditions hold, for example because a required profile,
version declaration, or alignment artifact could not be obtained
or validated.
Equality of ontology identifiers or membership in the same major
version series MUST NOT, by itself, establish compatibility. A
profile that permits compatibility across versions MUST define the
applicable relationship and constraints. Unavailability of required
information MUST NOT be reported as a completed finding of
incompatibility.
A receiver MUST NOT proceed on the assumption that decision-sensitive
semantic compatibility has been established when the result is
Incompatible or Indeterminate. A separately negotiated profile or
explicit fallback procedure MAY be used, provided that its
requirements are validated and required constraints are not silently
relaxed. Semantic compatibility does not establish authorization or
execution admission.
The participant making the decision MUST retain the distinction
between Incompatible and Indeterminate. The carrier binding
determines whether and how that distinction is exposed to another
participant, taking disclosure policy into account.
A completed evaluation finding that a required condition is violated
is Incompatible. Multiple competing candidate mappings, an unknown
required version relationship, or an unavailable required validation
input is Indeterminate. A malformed baseline envelope is rejected as
invalid input before evaluating compatibility; it MUST NOT be treated
as Compatible.
7.2. Alignment Artifacts
An alignment artifact used for decision-sensitive processing MUST
identify its source and target ontologies, the applicable source and
target versions, the mapping direction, and the scope and constraints
under which the mapping is valid. Its revision and provenance MUST
be available for validation. Any validity limits required by the
deployment MUST be evaluated before the artifact is used.
Zhang, et al. Expires 22 April 2027 [Page 17]
Internet-Draft Semantic Interaction for IoA October 2026
Validation of an artifact's integrity or signature does not, by
itself, establish that its issuer is authorized to define an
acceptable mapping. Acceptance also depends on the receiver's trust
policy and the artifact's applicability to the requested use.
An artifact MUST define the meaning and direction of each mapping
rule, including any parameter, input/output, unit, or domain
conditions needed for its use. A reverse mapping or a chain of
mappings MUST NOT be inferred to be valid unless its direction and
composition conditions are explicitly defined. An absent required
condition cannot be repaired by a confidence score.
7.3. Conflict Resolution Rules
Mappings that are untrusted, inapplicable, expired, or inconsistent
with required constraints MUST be excluded before resolving
alternatives. If multiple applicable mappings remain, the
participants MUST use an explicitly defined selection rule or
negotiate an unambiguous mapping. A receiver's local selection MUST
NOT be assumed to establish the peer's agreement. If the required
mapping cannot be established unambiguously, the result is
Indeterminate.
7.4. Candidate Mapping Generation
Implementations MAY use lexical, structural, behavioral, heuristic,
or model-assisted techniques to discover candidate mappings.
Candidate generation is an implementation choice and is not a
conformance requirement of this specification.
A candidate mapping or confidence score MUST NOT, by itself,
establish decision-sensitive semantic compatibility. A candidate
used for that purpose MUST first satisfy the validation and
acceptance rules for alignment artifacts. Confidence values from
different generators MUST NOT be assumed to have a shared calibration
or probability interpretation.
Descriptive similarity does not establish equivalence of input
constraints, units, output semantics, permitted targets, or
operational scope. Any such conditions required by the applicable
profile MUST be preserved and validated.
Zhang, et al. Expires 22 April 2027 [Page 18]
Internet-Draft Semantic Interaction for IoA October 2026
8. Discovery and Capability Semantics
Discovery mechanisms MAY use capability descriptions and candidate
mappings to locate potentially relevant providers. A capability
advertisement need not supply a task-specific intent. A response
claiming compatibility for a concrete task MUST identify the proposed
semantic profile and mapping revision, and MUST distinguish that
claim from a candidate recommendation.
Directory lifecycle, synchronization, ranking, and final provider
selection are outside this semantic profile. An incomplete directory
lookup or an unresolved reference does not prove that no capable
provider exists. Directory information used in a compatibility check
remains subject to its own validity and provenance requirements
[DIRECTORY].
9. Interaction Semantics
Interaction messages using this profile SHOULD carry a semantic
envelope or an unambiguous reference to the accepted profile. A
binding MUST associate all dependent operations with that accepted
revision even when the envelope is not repeated in every message.
Profiles MUST remain stable for the accepted use unless the affected
interpretation is renegotiated and recorded.
A carrier binding for decision-sensitive use of this profile MUST
specify how the semantic profile and its accepted revision are
associated with the relevant task or operation, participants, and
intended service. It MUST identify which existing interaction and
security mechanisms protect that association and provide the
authentication, authorization, integrity, and freshness checks
required by the deployment.
A semantic identifier or profile reference alone does not
authenticate a participant, establish a delegation, or authorize an
operation. A change to a decision-relevant profile, mapping,
intended service, or associated security context MUST trigger
validation of the affected assumptions before further reliance on the
previous compatibility result. Resuming a dialog or retaining a task
identifier does not by itself establish that those assumptions remain
valid.
This specification does not define a new credential, signature
format, dialog recovery procedure, or authorization decision
protocol.
Zhang, et al. Expires 22 April 2027 [Page 19]
Internet-Draft Semantic Interaction for IoA October 2026
Natural language MAY remain the primary task content, including in an
NLIP-style realization [DMSC-NLIP-NOTES]. Descriptive content does
not replace required decision-sensitive identifiers or constraints.
The task lifecycle, retries, streaming, and treatment of an operation
with an unknown execution outcome remain the responsibility of the
carrier and application protocol.
10. Relationship to A2A
A2A 1.0.0 provides AgentCard, AgentSkill, Message, Task, Artifact,
metadata and extension mechanisms [A2A-SPEC]. Those mechanisms can
advertise and carry semantic information; this document does not
change their lifecycle, authentication or authorization behavior.
* An AgentCard SHOULD advertise the applicable semantic extension
identifier and supported ontology/profile versions.
* A carrier binding SHOULD identify the metadata location for the
envelope or its reference, required-extension handling, and the
accepted revision.
* A deployment requiring semantic processing MUST NOT treat an
optional advertisement alone as proof that a peer accepted the
profile.
The example in Section 12.2 is only a fragment of an extension
advertisement. It is not a complete Agent Card or a standardized A2A
semantic extension.
11. Relationship to Directory, Mediation, and Other Protocol Work
Externally supplied descriptions, such as A2A Agent Cards or ANML
documents, can provide source information for a gateway-local
semantic view. A deployment-specific mapping MUST state which source
fields are preserved, which are transformed, and which cannot be
represented without loss. No generic lossless mapping or
interoperability with those formats is implied by this specification.
Gateway directory procedures manage the provenance, versions,
lifecycle, and visibility of capability information. This
specification provides semantic interpretation rules for information
used by those procedures and does not define their synchronization
behavior. A gateway mediation function can consume both the
directory information and a semantic compatibility result as inputs
to a separate policy-controlled decision.
Zhang, et al. Expires 22 April 2027 [Page 20]
Internet-Draft Semantic Interaction for IoA October 2026
The semantic Context described here is domain- or task-specific
interpretation information. It is distinct from the minimal
identifiers and lifecycle state that constitute dialog context in the
AgentProto charter.
ANML is an example of an external machine-readable description
[ANML]. The directory and mediation boundaries above correspond to
[DIRECTORY] and [MEDIATION]. The dialog-context distinction follows
[AGENTPROTO]. These are complementary references, not a claim of
cross-implementation interoperability.
In the ACPs and infrastructure architecture proposals, discovery
matching and interaction protocols can consume SemanticProfile
without having this document define their wire procedures [ACPs-ARC]
[INF-ARCH]. Concrete task exchanges and an NLIP realization are
examples of carriers [IoA-Task] [DMSC-NLIP-NOTES].
12. Example Flows
All examples in this section are non-normative. Outcome labels
illustrate logical results, not new protocol error codes. They
describe expected processing under the stated profile assumptions;
they do not report implementation test results.
12.1. Cross-Domain Candidate and Accepted Mapping
A requester needs technical-document translation from Chinese to
English. A provider advertises a document-translation capability
under a different ontology. A lexical score of 0.91 identifies a
candidate only. For a Compatible result the receiver must validate
an accepted directional mapping covering the exact ontology versions,
text/plain input/output, language pair, and computer-science domain
required by the task. If the mapping cannot be obtained or accepted,
the result is Indeterminate; if a completed check establishes a
conflicting required constraint, the result is Incompatible.
12.2. A2A Extension Advertisement Fragment
Zhang, et al. Expires 22 April 2027 [Page 21]
Internet-Draft Semantic Interaction for IoA October 2026
{
"capabilities": {
"extensions": [
{
"uri": "https://example.org/extensions/semantic-profile/v1",
"required": false,
"params": {
"ontologyIds": [
"https://example.org/onto/agent-core"
],
"ontologyVersions": [
"1.0"
]
}
}
]
}
}
The extension URI is an example identifier, not a registered
extension or a guarantee of peer support. The complete Agent Card,
extension activation, and message carriage follow the selected A2A
binding.
12.3. Interaction and Domain Validation
The envelope in Section 6.2 binds LLM to cs:LargeLanguageModel. In a
technical-translation profile that permits only computer-science
senses for this binding, replacing that sense with law:MasterOfLaws
creates an incompatible domain condition. The fragment below
specifies the single replacement applied to the otherwise complete
envelope; it is not a standalone envelope.
{
"term": "LLM",
"sense": "https://example.org/onto/law#MasterOfLaws"
}
A profile allowing cross-domain terminology could instead accept that
binding. The result depends on explicit profile constraints, not on
rejecting every task involving multiple domains.
12.4. Alignment Artifact Example
Zhang, et al. Expires 22 April 2027 [Page 22]
Internet-Draft Semantic Interaction for IoA October 2026
{
"artifactId": "https://example.org/align/cs-doc-v1",
"revision": "1",
"sourceOntologyId": "https://example.org/onto/agent-core",
"sourceOntologyVersion": "1.0",
"targetOntologyId": "https://example.net/onto/doc",
"targetOntologyVersion": "2.0",
"direction": "source-to-target",
"assertedBy": "https://example.org/mapping-authority",
"validUntil": "2026-12-31T00:00:00Z",
"mappingRules": [
{
"from": "https://example.org/onto/cs#TechTranslation",
"to": "https://example.net/onto/doc#TranslateText",
"conditions": {
"inputMediaType": "text/plain",
"outputMediaType": "text/plain",
"sourceLang": "zh",
"targetLang": "en",
"domain": "https://example.org/onto/cs#ComputerScience"
}
}
],
"confidence": 0.91
}
This is an illustrative artifact shape, not a mandatory mapping wire
format. The conditions are defined for this example; an artifact
format must define their actual evaluation semantics. assertedBy is a
claim requiring external provenance validation, and validUntil is an
example validity bound, not a live trust guarantee. The score is
descriptive and does not authorize use of this mapping.
12.5. Processing Outcome Examples
* S1: Known profile and versions, validated references, and all
required constraints satisfied: Compatible, with separate
authorization still required.
* S2: Similarity score 0.99 without an accepted mapping: candidate
recommendation only; compatibility remains Indeterminate.
* S3: A completed check establishes that a required domain or unit
constraint conflicts: Incompatible; no implicit conversion or text
repair.
Zhang, et al. Expires 22 April 2027 [Page 23]
Internet-Draft Semantic Interaction for IoA October 2026
* S4: Required context or mapping retrieval is prohibited or
unavailable: Indeterminate, not a completed incompatibility or
provider-absence finding.
* S5: The intended service or accepted profile revision changes:
revalidate affected assumptions before reusing the prior result.
12.6. Illustrative NLIP-Style Carriage
An NLIP-style exchange can place the complete envelope from
Section 6.2 in a structured submessage alongside natural-language
content, using an encoding supported by that carrier. The carrier
binding must identify the submessage and protect its association with
the task. This example does not specify an NLIP message type, HTTP
endpoint, or mandatory submessage format [DMSC-NLIP-NOTES].
13. Compliance Requirements
A conforming implementation MUST state its roles (producer, consumer,
or both), supported serialization and carrier bindings, and
applicable domain profiles. A consumer MUST interpret the baseline
vocabulary, enforce envelope and domain constraints, apply strict
decision-sensitive processing, and retain the three compatibility
outcomes. A producer MUST emit well-formed values and identify the
profile revision used for an accepted interaction.
JSON-LD conformance additionally requires the term-expansion and IRI/
literal behavior in Section 6. A binding using another encoding MUST
document equivalent behavior. Conformance does not require a fuzzy
matcher, a reasoning engine, a universal domain ontology, or support
for every possible carrier.
14. Security Considerations
Semantic profiles may reveal sensitive capability and context
information. Implementations SHOULD consider:
* Minimizing semantic disclosure (least-information profiles).
* Integrity protection of semantic profiles and alignment artifacts.
* Access control on ontology registries and mapping services.
* Policy-based filtering of sensitive capabilities in discovery.
If a shared semantic knowledge base is used, implementers SHOULD
consider provenance, version control, and trust policies to prevent
poisoning or unauthorized changes.
Zhang, et al. Expires 22 April 2027 [Page 24]
Internet-Draft Semantic Interaction for IoA October 2026
Alignment artifacts can be a target for poisoning or downgrade
attacks. Implementations SHOULD validate alignment sources and
require provenance for mappings used in critical tasks.
A profile IRI, matching label, confidence score, or valid signature
is not in itself authorization. Trusted profile and mapping sources
must be selected under the relying party policy. Attackers may
substitute contexts, offer broad mappings that drop constraints, or
cause rollback to an earlier accepted profile. The strict-
processing, revision association, and retrieval controls in this
document address those risks without replacing the carrier security
mechanisms.
Domain context, capabilities, and detailed failure reasons can
disclose sensitive information. Receivers SHOULD minimize disclosure
and MAY return less detailed errors while retaining the completed-
failure versus Indeterminate distinction internally. Changes to
identity, delegation, service target, or other decision-relevant
context require validation by the appropriate security and
interaction layer.
15. IANA Considerations
This document makes no request for IANA action.
16. Acknowledgments
The authors thank Akira Okutomi and Aijun Wang for discussion of
strict processing of decision-sensitive semantic values
[STRICT-FEEDBACK]. The requirements in this revision are the
authors' proposed specification text.
17. Normative References
[JSON-LD] W3C, "JSON-LD 1.1", 2020,
<https://www.w3.org/TR/json-ld11/>.
[RDF11-CONCEPTS]
W3C, "RDF 1.1 Concepts and Abstract Syntax", 2014,
<https://www.w3.org/TR/rdf11-concepts/>.
[RDF-SCHEMA]
W3C, "RDF Schema 1.1", 2014,
<https://www.w3.org/TR/2014/REC-rdf-schema-20140225/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Zhang, et al. Expires 22 April 2027 [Page 25]
Internet-Draft Semantic Interaction for IoA October 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, 2017,
<https://www.rfc-editor.org/info/rfc8174>.
18. Informative References
[A2A-SPEC] Project, A., "A2A Protocol Specification, Version 1.0.0",
2026, <https://a2a-protocol.org/v1.0.0/specification/>.
[ACPs-ARC] Liu, J., Yu, K., Li, K., and K. Chen, "Agent Collaboration
Protocols Architecture for Internet of Agents", Work in
Progress, Internet-Draft, draft-liu-dmsc-acps-arc-03,
2026, <https://datatracker.ietf.org/doc/draft-liu-dmsc-
acps-arc/03/>.
[AGENTPROTO]
IETF, "Agent Communication Protocols Charter", Charter
charter-ietf-agentproto-01, 8 October 2026,
<https://datatracker.ietf.org/doc/charter-ietf-
agentproto/01/>.
[ANML] Jeskey, A., "Agentic Notation Markup Language (ANML) 1.0",
Work in Progress, Internet-Draft, draft-jeskey-anml-01,
2026, <https://datatracker.ietf.org/doc/html/draft-jeskey-
anml-01>.
[DIRECTORY]
Zhang, L., Yang, H., Li, Y., and S. Wang, "Gateway
Capability Directory and Synchronization for Internet of
Agents", Work in Progress, Internet-Draft, draft-zhang-
dmsc-gateway-directory-sync-02, 2026,
<https://datatracker.ietf.org/doc/draft-zhang-dmsc-
gateway-directory-sync/>.
[DMSC-NLIP-NOTES]
Verma, D., Bertino, E., Ratnaparkhi, A., and S. Hughes,
"Use of Natural Language for Agent Communication", Work in
Progress, Internet-Draft, draft-verma-dmsc-nlip-notes-00,
2026, <https://datatracker.ietf.org/doc/draft-verma-dmsc-
nlip-notes/00/>.
[INF-ARCH] Li, X. and A. Wang, "Dynamic Multi-agent Secured
Collaboration Infrastructure Architecture", Work in
Progress, Internet-Draft, draft-li-dmsc-inf-architecture-
03, 2026, <https://datatracker.ietf.org/doc/draft-li-dmsc-
inf-architecture/03/>.
Zhang, et al. Expires 22 April 2027 [Page 26]
Internet-Draft Semantic Interaction for IoA October 2026
[IoA-Task] Yang, C., "Internet of Agents Task Protocol", Work in
Progress, Internet-Draft, draft-yang-dmsc-ioa-task-
protocol-02, 2026, <https://datatracker.ietf.org/doc/
draft-yang-dmsc-ioa-task-protocol/02/>.
[MACP] Li, X., Liu, B., Liu, J., Du, C., and L. Zhang, "Multi-
agent Collaboration Protocol Suites Architecture", Work in
Progress, Internet-Draft, draft-li-dmsc-macp-06, 2026,
<https://datatracker.ietf.org/doc/html/draft-li-dmsc-macp-
06>.
[MEDIATION]
Yang, H., Dong, G., Zhang, L., Li, Y., and S. Wang,
"Gateway Mediation Layer for AI Agent Collaboration", Work
in Progress, Internet-Draft, draft-yang-dmsc-gateway-
mediation-layer-00, 2026,
<https://datatracker.ietf.org/doc/html/draft-yang-dmsc-
gateway-mediation-layer-00>.
[OWL2-OVERVIEW]
W3C, "OWL 2 Web Ontology Language Overview", 2012,
<https://www.w3.org/TR/owl2-overview/>.
[SHACL] W3C, "Shapes Constraint Language (SHACL)", 2017,
<https://www.w3.org/TR/2017/REC-shacl-20170720/>.
[STRICT-FEEDBACK]
Okutomi, A., "Re: Anthropic report. Feedback requested",
11 June 2026,
<https://mailarchive.ietf.org/arch/msg/agent2agent/
wWJvFm02sVsUfgW56RcAjFVFfZA/>.
Appendix A. Change Log
RFC Editor: Please remove this appendix before publication.
A.1. Changes from -02 to -03
* Distinguished descriptive metadata, candidate mappings, and
decision-sensitive semantic values.
* Added strict processing and Compatible, Incompatible, and
Indeterminate outcomes; removed confidence-based decision
authority.
* Clarified directional alignment applicability, version handling,
and association with interaction/security context.
Zhang, et al. Expires 22 April 2027 [Page 27]
Internet-Draft Semantic Interaction for IoA October 2026
* Defined the baseline inline JSON-LD context, corrected RDF
property declarations, and reconciled vocabulary and examples.
* Made @id and @type explicit, adopted a provisional example.org
vocabulary namespace, and documented migration from earlier
example encodings.
* Clarified directory, mediation, A2A, ANML and AgentProto
boundaries and added processing examples.
Authors' Addresses
Lianhua Zhang
AsiaInfo Technologies (China) Inc.
Beijing
100000
China
Email: zhanglh2@asiainfo.com
Yun Li
AsiaInfo Technologies (China) Inc.
Beijing
100000
China
Email: liyun9@asiainfo.com
Huiling Yang
AsiaInfo Technologies (China) Inc.
Beijing
100000
China
Email: yanghl10@asiainfo.com
Shoufeng Wang
AsiaInfo Technologies (China) Inc.
Beijing
100000
China
Email: wangsf11@asiainfo.com
Zhang, et al. Expires 22 April 2027 [Page 28]