Ontology-based Semantic Interaction for Internet of Agents

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.¶
• 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.¶

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.¶

@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 .

@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.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"
    },
    "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"
    },
    "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"
    },
    "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"
      }
    ]
  }
}

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.¶

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.1. Compatibility Determination

Semantic compatibility processing MUST distinguish the following outcomes:¶

• 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.¶

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.¶

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

{
  "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

{
  "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.¶
• 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].¶

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.¶
• 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.¶