1     Definition 2     Functional Requirements 3     Syntax
4     Semantics 5    Conformance Testing 6     Performance Assessment

Definition

The digital representation of discourse relations and their arguments — semantic links between situations such as events, states, and propositions — designed to enable structured interpretation of discourse and explicit specification of relation types and argument roles across modalities.

Functional Requirements

MUST Requirements

  • Relation Core — MUST represent discourse relations with stable identifiers and core attributes:
    • type (relation label from a controlled vocabulary or profile),
    • explicitness (explicit | implicit),
    • asymmetry (boolean),
    • optional variant/sense (profile-specific refinement).
  • Argument Core — MUST represent relation arguments with:
    • role (e.g., Arg1, Arg2, ArgN),
    • references to content nodes (events, states, propositions) and/or segments (presentation units),
    • optional text/time spans for direct anchoring,
    • optional importance/weight (0..1).
  • Independent Annotation — MUST allow each relation to be annotated independently of other relations in the same discourse (no structural dependency required), while enabling cross‑links when present.
  • Anchoring & Connectives — MUST support connective anchoring (lexeme + text span) for explicit relations, and mark implicit relations with no connective or with inferred indicators.
  • Identity & Referencing — MUST ensure stable identifiers for relations and their arguments; support cross‑reference and uniqueness within an annotation instance.
  • Profile‑Based Relation Inventory — MUST permit profile vocabularies to constrain type and variant (e.g., Cause, Contrast, Condition, Elaboration, Temporal‑Before/After), without requiring any single ontology.
  • Multimodal Anchoring — MUST support anchoring arguments and/or connectives to text, audio, video, or other media via offsets, timestamps, frame indices.
  • Normalisation — MUST normalise identifiers to stable namespaces (URIs/IRIs) with language‑independent base IDs.
  • Trace — MUST record provenance metadata (origin, timestamp, tool/user, version) for relations and changes.
  • Extensibility — MUST allow controlled extension points (namespaces, custom attributes, domain vocabularies) without breaking conformance.

SHOULD Requirements

  • Profiles — SHOULD support domain‑specific profiles (e.g., dialogue, summarisation, clinical discourse) with additional constraints and enumerations for relation types, senses, and argument roles.
  • Quality Measures — SHOULD provide optional confidence scores, quality flags, and validation reports for relation detection/classification and argument span decisions.
  • Queryability — SHOULD facilitate efficient querying by relation type, explicitness, argument role, anchoring/segment linkage, modality, or provenance.
  • Hierarchy & Taxonomy Support — SHOULD support hierarchical classification of relations (e.g., Contrast → Antithesis) and role/argument subtyping for reasoning and analysis.
  • Defaulting & Implicit Inference — SHOULD represent conventional defaults (e.g., typical argument roles for a relation) and implicit relations with explicit markers and inference notes.
  • Cross‑Ontology Alignment — SHOULD provide mapping hooks to external resources (e.g., other Discourse Data Types, DR‑core inventories, Rhetorical Structure Theory (RST) and Penn Discourse Treebank (PDTB) mappings) without requiring any single ontology.
  • Multilingual Support — SHOULD support multilingual labels for relation types, senses, and connectives, and cross‑lingual alignment of relations and argument roles.

Syntax

https://schemas.mpai.community/MMC/V2.5/data/SemanticRelationsInDiscourse.json

Semantics

Label Semantics
Header Semantic Relations in Discourse Header (pattern MMC-SRD-V<Major>.<Minor>)
├─ Standard‑SRD MMC-SRD-V
├─ Version Major version – 1 or 2 digits (part of Header pattern)
├─ Dot‑separator The character ‘.’ separating version components (part of Header pattern)
├─ Subversion Minor version – 1 or 2 digits (part of Header pattern)
trace Provenance metadata for the SRD instance; REQUIRED fields: origin and timestamp; no additional properties allowed.
├─ origin Identifier of the creator/source of the SRD annotation (e.g., module name, system ID, annotator). Type: string.
├─ timestamp Creation time of the SRD instance in RFC 3339 / ISO 8601 date-time format (e.g., 2025-12-14T21:03:00Z). Type: string.
relations[] Array of Discourse Relation objects; minItems=1. Each item conforms to $defs.Relation.
metadata Optional descriptive metadata for the SRD instance; may include language, schemaVersion, and profileVocabulary.
├─ language Language tag of the discourse (e.g., en, pt-PT). Type: string.
├─ schemaVersion Version string of the JSON Schema used to validate this instance. Type: string.
├─ profileVocabulary Identifier (string) of the vocabulary constraining Relation.type values (e.g., URI or profile name).
Relation Discourse Relation object; REQUIRED fields: relationId, type, arguments.
├─ relationId Stable identifier of the relation instance; enables referencing and tracing. Type: string.
├─ type Relation type label; interpretation constrained by metadata.profileVocabulary. Type: string.
├─ variant Optional pragmatic/sense variant (profile-specific). Type: string.
├─ explicitness Realisation status of the relation: explicit or implicit. Enum: {explicit, implicit}.
├─ connective Optional object capturing the connective lexeme and its span in text.
│  ├─ lexeme Surface form of the connective as a string (e.g., because, although). Type: string.
│  ├─ textSpan Character offsets of the connective as [start, end) integers; minItems=2, maxItems=2.
├─ asymmetric Boolean flag indicating directedness/asymmetry of the relation (true if Arg1→Arg2 order matters).
├─ arguments[] Array of Argument objects; minItems=2. Roles designate Arg1, Arg2, or ArgN.
├─ hierarchyPath Optional classification path as an array of strings (e.g., [“Contrast”,”Antithesis”]).
├─ attributes Open object for additional relation-specific metadata; unconstrained.
Argument Relation Argument object; REQUIRED field: role. Provides anchoring and references for each argument.
├─ role Argument role label; Enum: {Arg1, Arg2, ArgN}. Type: string.
├─ contentRef Identifier of the content node serving as the argument (e.g., event/state/proposition). Type: string.
├─ segmentRef Identifier of the segment linked to this argument (if directly anchored to presentation). Type: string.
├─ textSpan Character offsets of the argument span as [start, end) integers; minItems=2, maxItems=2.
├─ timeSpan Media time alignment as [start, end) seconds (numbers); minItems=2, maxItems=2.
├─ importance Optional relative importance weight of the argument in [0..1]. Type: number.
├─ attributes Open object for per-argument metadata; unconstrained.

5     Conformance Testing

A Data instance Conforms with MPAI-MMC Belief (MMC-EBL) if:

  1.  Its JSON Object validates against its JSON Schema.
  2. Any included  JSON Object validates against its JSON Schema.
  3. All Data in the JSON Object:
    1. Have the specified Data Types.
    2. Conform with the Qualifiers signaled in their JSON Schemas.

6     Performance Assessment