The Conversational Interaction Ontology defines domain-neutral RDF terms for conversations, contributions, threads, records, ordered views, addressing, targets, semantic reactions, lifecycle, provenance, and human or software-agent execution. Its short name is the Conversation Ontology.
This is an unofficial 0.1 Editor's Draft maintained by Inferal. Feedback should be sent to contact@inferal.com.
Conversation data is often modeled as a list of messages. That works until the same exchange is exported twice, a reply branches, a message is delivered to several recipients, a contribution is regenerated, or an uncertain historical transcript must preserve conflicting evidence. At that point, a single message list has been asked to represent an interaction, its informational units, a reply graph, a display order, transport events, and an evidential record at the same time.
The Conversation Ontology separates those concerns while keeping them in one vocabulary. It provides a common semantic foundation for chat, email, forums, spoken dialogue, document review, issue discussion, archives, and human/AI/tool workflows. Applications can use the small core and adopt richer parts only when their data needs them; those parts are not separate ontologies or competing models.
This specification is intended for RDF publishers, platform and data model designers, archivists, interoperability engineers, and authors of conversation-aware agents. A publisher can expose current platform data; an importer can preserve distinctions from a source system; and an analyst can query across records without assuming that every source uses the same presentation or delivery model.
The ontology does not prescribe a user-interface layout, infer reply edges from adjacency, define a universal state machine, replace transport protocols, or duplicate selector, ordering, uncertainty, and provenance vocabularies. It also does not claim that a platform message identifier denotes the interaction itself. Source-specific equivalences and projections belong in separately reviewed mappings.
The model is scoped and evaluated by the following questions without collapsing their answers into one overloaded relation:
This visible list is also a machine-readable
Competency Question Ontology
corpus. Each list item is a visible carrier for a persistent
cqo:CompetencyQuestion label. A separate generated carrier
preserves the distinct language-tagged
cqo:QuestionFormulation; an unannotated nested span keeps
that formulation IRI addressable in the visible page without asserting
a second statement inside the literal carrier. HTML/RDF does not permit
a literal carrier to contain another asserted statement. The extracted
named graph connects both resources to the question's kind, purpose,
target ontology, requirement, use case, stakeholder, answer
expectation, lifecycle state, and review state. The first two questions
are scoping questions. The remaining questions are
validation questions: even questions about reply or authorship links
retrieve domain content rather than asking about the formal
characteristics of a relationship.
Try the CQ layer. Open the RDF Navigator and run
List competency questions by kind or
Inspect CQ formalization coverage from Suggested queries. The
query resources are both cqo:FormalQuery artifacts and
Navigator-discoverable sh:SPARQLSelectExecutable
resources. Their executable source is processor input; extraction does
not turn SPARQL into ontology semantics or SHACL validation.
The key words MUST, SHOULD, and MAY are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.
Vocabulary conformance means using terms according to this specification. A graph claiming a named SHACL profile MUST satisfy that profile in addition to the vocabulary-wide shapes. Profiles are conformance contracts over one ontology; they are not separate conversation ontologies or namespaces.
The ontology and OWL addendum state open-world meaning. Vocabulary-wide shapes validate intrinsic well-formedness when a construct is used. Named profiles add closed-world completeness requirements. Validators MUST accept either direction of a declared inverse and MUST NOT require redundant inverse triples merely to establish conformance. Validators MUST load the ontology distribution as their ontology graph so local controlled values and RDFS entailments are available to SHACL.
The namespace is
https://ontology.inferal.com/modules/conversation/ and the
preferred prefix is convo.
This specification is also an IA² HTML/RDF 0.1 document. Its live DOM carries the portable vocabulary, the optional OWL entailment layer, the base SHACL validation contract, and a semantic description of this specification as four separate named graphs. The RDF Navigator can inspect and serialize those graphs without dereferencing the ontology distributions. Extraction records OWL and SHACL statements; it does not perform inference or validation.
The document graph describes this page as a
FaBiO
specification document. It uses
DoCO
for sections and headings,
DEO
for rhetorical roles, and the
Pattern Ontology
for structural containment. References carry citation intent from
CiTO.
Definition fragments and model sections use
dcterms:subject to identify the Conversation terms they
explain. These document annotations reuse external IRIs without adding
OWL imports to the Conversation Ontology.
A conversation is the communicative interaction itself and is a PROV activity. Contributions, threads, content, and records are entities. This distinction permits one continuing interaction to have multiple platform records, exports, reconstructions, and transcripts without identifying the interaction with any one artifact.
Conversation membership, thread grouping, reply topology, presentation order, addressing, transport, targeting, and provenance are orthogonal. Applications MUST NOT infer reply edges solely from adjacent display positions, thread co-membership, delivery order, or shared provenance. Likewise, a reply edge does not establish a unique display position.
| Question | Primary construct | What it does not imply |
|---|---|---|
| What interaction occurred? | convo:Conversation | A particular log, transcript, or platform container. |
| What was contributed? | convo:Contribution | A unique author, delivery, reply parent, or display position. |
| Which interaction contains it? | convo:contributionOf | Thread membership or reply topology. |
| What does it answer? | convo:inReplyTo | Adjacency, exclusive parentage, or the same conversation. |
| How is it grouped? | convo:inThread | A tree or an ordering. |
| Where is it displayed? | convo:OrderedMembership and a locus | A global index intrinsic to the contribution. |
| How did it reach someone? | convo:MessageTransmission and convo:Delivery | Authorship or intended addressing. |
| How was it produced? | convo:ContributionAct and PROV | Its conversational role or transport sender. |
These constructs form one connected ontology. The conceptual parts are boundaries within the model, not separately versioned modules. This keeps ordinary data easy to combine while allowing profiles to select only the commitments needed for a particular exchange.
convo:Conversation denotes a communicative
prov:Activity. It MAY exist without recorded contributions,
for example while proposed, open, or reconstructed from incomplete
evidence.
convo:Participation qualifies an agent's participation in
one conversation. Generic participation does not imply causal or
managerial responsibility. When PROV responsibility is intended,
convo:ResponsibleParticipation MUST be used as a qualified
prov:Association with the corresponding PROV agent.
Attendance is not necessarily responsibility. A listener, copied recipient, automated observer, or transient participant can participate without controlling the activity. Conversely, a moderator or facilitator may bear qualified responsibility even when they authored no contribution. Roles describe the capacity in which an agent participated; they do not replace the agent.
convo:Contribution is the broad informational unit. Messages, utterances, comments, questions, answers, reactions, system notices, tool calls, and tool results specialize it. A contribution in the Core Profile MUST identify at least one conversation through convo:contributionOf or inverse convo:hasContribution. A contribution MAY participate in multiple conversations or threads. Applications needing exclusive membership must declare that restriction in a narrower profile.
convo:Thread is a grouping within one conversation. convo:inReplyTo expresses reply topology independently of thread membership. A contribution MUST NOT reply to itself. The Threaded Conversation Profile additionally requires acyclicity and thread/conversation membership consistency. A cross-conversation reply is permitted but reported for review because it may resume an archived interaction.
Missing or unavailable parents MAY remain as minimally described contribution resources so surviving reply edges retain their target. A tombstone MAY represent an unavailable contribution without fabricating its payload.
| Relation | Meaning | Typical cardinality |
|---|---|---|
| convo:contributionOf | Membership in an interaction. | One or more under Core; not globally exclusive. |
| convo:inThread | Membership in a conversation-local grouping. | Zero or more. |
| convo:inReplyTo | A directed response edge. | Zero or more; self-replies are invalid. |
| convo:answers | An answer relation more specific than a generic reply. | Zero or more. |
| convo:references | A non-reply informational reference. | Zero or more. |
A convo:Reaction is an identifiable contribution occurrence. It can therefore carry an actor, generation time, source token, provenance, invalidation, and replacement history. convo:reactsTo identifies exactly one target under the base shapes, while one or more convo:hasReactionType values classify what kind of reaction was expressed. The target need not be a contribution, and a reaction does not thereby become a reply.
A convo:ReactionType is a SKOS concept. The built-in convo:ReactionTypes scheme is an open semantic pivot, not a closed enumeration. Its values are non-exclusive: for example, one source reaction might reasonably be both convo:Like and convo:Acknowledge. A reaction type describes the communicated function of the reaction; it MUST NOT be treated as proof of an agent's private emotional state.
Platform-native and community-native reaction concepts SHOULD remain
in their own SKOS concept schemes. Publishers MAY relate those concepts
to built-in values with skos:exactMatch,
skos:closeMatch, or skos:relatedMatch, choosing
the weakest relation supported by evidence. An exact platform type and
a publisher-asserted semantic type MAY coexist on one reaction. Emoji,
shortcodes, and custom event keys have no context-free global meaning;
publishers SHOULD preserve the source token with convo:text or
an identifiable convo:Content representation.
Consumers calculating current counts SHOULD count distinct reaction occurrences that are not invalidated. A source-provided aggregate count is evidence for the count only; it MUST NOT be expanded into invented reaction occurrences, actors, or timestamps.
A convo:ConversationRecord records one conversation. An
convo:OrderedView presents contributions through
convo:OrderedMembership occurrences; a transcript is one
such view. Each membership identifies the contribution and a
loc:Locus in the view's position frame.
A sequence position belongs to a named convo:ContributionSequenceFrame, which MAY refer to an Ordering Ontology context. Implementations MUST NOT interpret a rank or locus value as a universal contribution index outside that frame. Competing or uncertain time claims MAY use Localization, Range, Confidence, and PROV without adding them to the core profile.
Ordered membership is intentionally reified. The same contribution can occur once in a chronological transcript, again in a moderated view, and at a different position in a reconstructed archive. Each occurrence receives its own locus in the frame of that view. The contribution remains a single entity unless the source actually supplies distinct versions.
Records may be incomplete or derived. Publishers SHOULD use PROV to relate an export, reconstruction, redacted transcript, or summary to its sources. A record's order is evidence about that record, not by itself evidence of reply structure or generation time.
Authorship, addressing, transmission, and delivery describe different
facts. convo:Addressing qualifies an addressee and its role.
convo:MessageTransmission identifies what was sent and by
whom or what account. A service acting as sender is represented as a
prov:SoftwareAgent. Recipient-specific convo:Delivery
activities can then record delivery or receipt independently. Data
publishers SHOULD apply access controls before exposing blind-copy
addressing.
convo:discusses relates a conversation to an artifact. convo:Target qualifies a contribution's target with its source, optional selector, and optional purpose. Selectors MAY use Web Annotation or another selector vocabulary; this ontology does not duplicate selector syntax.
| Fact | Construct | Example |
|---|---|---|
| Intellectual responsibility | prov:wasAttributedTo or convo:authoredBy | Alice wrote the message. |
| Submission | convo:submittedBy | Alice's assistant submitted it. |
| Intended addressing | convo:Addressing | Bob was a primary recipient; Carol was copied. |
| Transmission | convo:MessageTransmission | A mail service sent the contribution. |
| Recipient event | convo:Delivery | Bob's account received a delivery. |
| Presentation | convo:displayedAt | A client displayed it later. |
Blind-copy addressing is sensitive by design: RDF publication can make an otherwise hidden relationship discoverable. Producers MUST apply authorization and redaction policy before disclosing such statements; ontology conformance does not grant permission to publish them.
convo:ConversationStatus values identify exactly one convo:StatusDimension: operational, resolution, or retention. This permits simultaneous statements such as operationally closed, substantively resolved, and retained as an archive without treating those values as one exclusive state machine. A qualified convo:ConversationStatusAssignment applies to either a conversation or a thread and MAY carry provenance.
Instant-like values on conversation-owned time properties MUST be
xsd:dateTimeStamp or timezone-bearing
xsd:dateTime. Generation, authorship, transmission,
delivery, receipt, display, and closure times are distinct facts.
Stable, uncertain, or contested positions use Localization loci and
separate localization claims.
Direct status assertions express the status currently reported by the graph. Qualified assignments preserve who made an assignment, when, and on what evidence. The two forms can coexist. Consumers SHOULD group statuses by convo:hasStatusDimension rather than assuming all status values compete for one slot. Distinct direct statuses in the same dimension are permitted so conflicting reports are not discarded, but the base shapes emit a warning. Publishers SHOULD use qualified assignments when disagreement, provenance, or status history matters.
Time modeling follows an escalation path: use direct timestamps for an ordinary known instant; use qualified PROV times when the event and its provenance matter; use a Localization locus when a position depends on a frame; and use localization claims with Range and Confidence when estimates conflict or remain uncertain. A publisher SHOULD preserve distinct claims rather than average them into a false exact instant.
PROV-O is the provenance foundation. Implementations SHOULD use PROV generation, attribution, association, derivation, invalidation, and qualified time instead of local substitutes. Direct conversation properties provide only domain-specific distinctions or common timestamp conveniences.
A convo:ContributionAct generates contributions. Human acts, model invocations, and tool invocations specialize it. A model invocation identifies its model and MAY identify a separate configuration. A tool invocation identifies the tool, request, inputs, and generated tool results. Contribution roles distinguish user, assistant, system, and tool positions without treating those roles as agents or authorship.
A typical agent run is modeled as a contribution act associated with a responsible software agent, using prompt or context entities and a model configuration, and generating an assistant contribution. A tool invocation can use the assistant's tool-call contribution, identify the invoked tool, and generate a tool-result contribution. The next model invocation may then use that result. This chain remains ordinary PROV-O, so provenance tools can inspect it without conversation-specific execution logic.
Version relations are deliberately specific. A revision edits an earlier expression; a superseding contribution replaces it in a workflow; an alternative coexists; a regeneration records a new model attempt; a redacted version removes information; and a summary condenses one or more sources. Publishers SHOULD select the narrowest truthful relation and MAY add PROV derivation where appropriate.
Meaning and validation serve different purposes. RDFS and OWL describe open-world relationships. Vocabulary-wide SHACL shapes reject intrinsic contradictions such as a self-reply or malformed qualified construct. Named profiles add dataset-level completeness requirements for an interchange agreement.
| Layer | Purpose | Example |
|---|---|---|
| Ontology | Defines terms, domains, ranges, and reusable entailments. | A transcript is an ordered view. |
| OWL addendum | Adds conservative inverses and characteristics. | hasReply is inverse to inReplyTo. |
| Vocabulary-wide shapes | Checks a construct whenever it appears. | An ordered membership identifies its view, contribution, and locus. |
| Named profile | States what a claimed dataset must include. | The Transcript Profile requires a position frame and explicit occurrences. |
A violation indicates failure of a claimed constraint. A warning marks a condition that is legal in the general model but commonly deserves review, such as a cross-conversation reply or missing local text. Shape paths are inverse-aware, so a graph need not duplicate both directions of every inverse relation. Position-aware validation additionally loads the Localization, Ordering, Range, and Confidence constraints needed by that profile.
The following query families are useful both for explanation and for implementation tests. They inventory contribution membership, find branch points, audit cross-conversation replies, recover view-local positions, separate responsibility from delivery, group status by dimension, identify same-dimension status conflicts, trace agent execution, count non-invalidated reaction occurrences while retaining source types, retain unavailable parents, and surface competing temporal claims.
PROV-O is the required conceptual foundation for agents, activities, entities, derivation, attribution, association, generation, and invalidation. SKOS supplies concepts, concept schemes, notation, and conservative mapping relations for reaction types. Localization is an optional sibling capability used for contextual position; Ordering supplies order relations; Range and Confidence describe uncertain or contested positions. These vocabularies are reused rather than copied into the Conversation namespace.
Other conversation, messaging, annotation, or activity vocabularies can be imported through explicit mappings. Such mappings SHOULD state whether they are logical alignments or executable projections, document loss and coverage, and avoid OWL equivalence unless both directions truly preserve meaning. The base ontology therefore remains usable before any source-specific mapping is selected.
Conversation graphs can reveal identities, participation, private recipients, reaction patterns, moderation actions, deleted content, model prompts, tool inputs, and provenance not visible in a transcript. Implementations MUST apply access policy to the graph as a whole rather than assuming that removal of literal text removes sensitive relationships.
Publishers SHOULD minimize or pseudonymize agents and accounts where appropriate, protect blind-copy addressing, avoid exposing selectors into restricted resources, and review provenance chains for copied sensitive inputs. Tombstones SHOULD preserve only the identity and topology required by the use case. A redacted record SHOULD use explicit provenance so consumers do not mistake it for a complete original.
Profiles are described with PROF resource descriptors. Each descriptor
identifies its SHACL artifact, media type, conformance language, and
constraints/validation role. Instance data MAY state
dcterms:conformsTo; external profile selection is equally
conformant.
| Profile | Required | Warnings | Not required or prohibited |
|---|---|---|---|
convo:ConversationCoreProfile | Every Contribution has at least one Conversation membership. | Missing local content/text or attribution, except for tombstoned contributions. | Does not require one exclusive conversation, a thread, a reply, or a record. |
convo:ThreadedConversationProfile | Every Thread has at least one contribution; thread and conversation memberships agree; reply graph is acyclic. | Reply endpoints having no conversation in common. | Does not require a tree, one reply parent, or display order. |
convo:TranscriptProfile | Each OrderedView has exactly one frame and at least one occurrence; each occurrence has exactly one view, contribution, and locus; contribution belongs to the recorded conversation. | None defined. | Does not require reply edges or equate locus values with global indices. |
convo:AddressedMessageProfile | Addressing has exactly one Message, addressee, and role; Transmission has exactly one Message and agent/account sender; Delivery has exactly one transmission and recipient. | None defined. | Does not infer author, intended addressee, sender, and recipient from one another. |
convo:ArtifactDiscussionProfile | Every selected Conversation discusses at least one IRI resource. | None defined. | Does not require a topic taxonomy or contribution-level target. |
convo:TargetedCommentProfile | Every Comment has a Target; each Target has exactly one source and at most one selector. | None defined. | A selector is optional for a whole-resource target. |
convo:ProvenanceRichProfile | Every Contribution has generation activity and attribution; generation is reciprocal; ContributionActs have a responsible agent and output; derivation targets have the expected type; invalidation records both activity and time. | None defined. | Does not require all provenance to use direct Conversation convenience properties. |
convo:PositionAwareProfile | All Transcript requirements; sequence frame has exactly one ordering; membership locus uses the view's frame; generation loci are Localization loci; composed Localization, Ordering, Range, and Confidence constraints apply. | Those produced by composed profile shapes. | Does not force uncertain claims into one direct timestamp. |
convo:AgentExecutionProfile | ModelInvocation has one model, responsible software agent, and output; ToolInvocation has one tool and request plus ToolResult output; ToolResult generation is reciprocal; every Contribution has exactly one contribution role. | None defined. | Contribution role does not replace author, agent, or participation role. |
Selecting several profiles forms the conjunction of their constraints. A graph claiming both Transcript and Agent Execution, for example, must provide contextual view positions and complete execution roles. No precedence rule causes one profile to weaken another.
All terms below are in the Conversation namespace. Their labels, comments, subclass or subproperty relations, domains, and ranges in the ontology distribution are normative. Subtypes inherit the basic shape of their nearest shaped superclass. Marker classes and controlled role or status values have no additional base shape when they introduce no intrinsic property constraint; named profiles validate their use.
| Area | Terms | Boundary |
|---|---|---|
| Interaction | convo:Conversation, convo:Participation, convo:ResponsibleParticipation, convo:ParticipantRole | The interaction is an activity; participation qualifies an agent without implying PROV responsibility unless responsible participation is used. |
| Contributions | convo:Contribution, convo:Message, convo:Utterance, convo:Comment, convo:Question, convo:Answer, convo:Reaction, convo:ReactionType, convo:SystemNotice, convo:ToolCall, convo:ToolResult, convo:Content, convo:Thread | A Contribution is the broad entity; reaction classification, packaging, reply topology, grouping, and content representation remain separate. |
| Records and position | convo:ConversationRecord, convo:OrderedView, convo:Transcript, convo:OrderedMembership, convo:ContributionSequenceFrame | A record represents an interaction; order belongs to a membership occurrence in a view-specific Localization frame. |
| Messaging | convo:Account, convo:Addressing, convo:AddressingRole, convo:MessageTransmission, convo:Delivery | Accounts, authorship, addressing, transmission, and recipient-specific delivery denote different facts. |
| Targeting | convo:Target | A target qualifies a whole resource or selected fragment without duplicating selector vocabularies. |
| Lifecycle | convo:ConversationStatus, convo:StatusDimension, convo:ConversationStatusAssignment, convo:ModerationAction, convo:Tombstone | Status values are dimensioned individuals; assignments and moderation carry history while tombstones preserve unavailable identity. |
| Execution | convo:ContributionAct, convo:HumanContributionAct, convo:Model, convo:ModelConfiguration, convo:ModelInvocation, convo:Tool, convo:ToolInvocation, convo:ContributionRole | Production is a PROV activity; models and configurations are entities, tools are software agents, and contribution roles are not authors. |
| Area | Terms | Meaning |
|---|---|---|
| Participation | convo:hasParticipation, convo:participationIn, convo:hasParticipant, convo:participationRole, convo:beganAt, convo:endedAt | Qualifies who participated, in which conversation and role, and during which optional interval. |
| Membership | convo:hasThread, convo:threadOfConversation, convo:hasContribution, convo:contributionOf, convo:hasThreadContribution, convo:inThread | States conversation and thread membership independently of replies. |
| Reply, reaction, and reference | convo:inReplyTo, convo:hasReply, convo:answers, convo:reactsTo, convo:hasReactionType, convo:quotes, convo:mentions, convo:references | Distinguishes response, answer, reaction target and type, quotation, mention, and general reference semantics. |
| Content and responsibility | convo:hasContent, convo:text, convo:hasAttachment, convo:authoredBy, convo:submittedBy, convo:authoredAt | Separates contribution identity, representation, attachment, author, submitter, and authorship time. |
| Records and position | convo:recordsConversation, convo:hasOrderedMembership, convo:orderedMembershipOf, convo:membershipContribution, convo:membershipLocus, convo:hasPositionFrame, convo:hasGenerationLocus, convo:displayedAt | Connects records to interactions and positions contributions contextually rather than globally. |
| Accounts and addressing | convo:representsAgent, convo:hasAddressing, convo:addressingOf, convo:addressee, convo:hasAddressingRole, convo:addressedTo, convo:hasAudience | Separates account representation, qualified addressing, convenience addressing, and intended audience. |
| Transport | convo:transmitsContribution, convo:transmissionSender, convo:hasDelivery, convo:deliveryOf, convo:deliveryRecipient, convo:sentAt, convo:deliveredAt, convo:receivedAt | Describes sending and recipient-specific delivery independently of content creation. |
| Discussion and targeting | convo:discusses, convo:hasTopic, convo:hasTarget, convo:sourceResource, convo:selector, convo:targetPurpose | Distinguishes discussion subject, topic, and qualified whole-resource or fragment target. |
| Status and moderation | convo:hasStatus, convo:hasStatusDimension, convo:statusOf, convo:assignedStatus, convo:assignedAt, convo:moderates, convo:tombstoneFor, convo:closedAt | States current dimensioned status, qualified status history, moderation targets, and unavailable contributions. |
| Versions and alternatives | convo:revisionOf, convo:supersedes, convo:alternativeTo, convo:regenerationOf, convo:redactedVersionOf, convo:summaryOf | Keeps editing, replacement, alternatives, regeneration, redaction, and summarization distinct. |
| Agent execution | convo:usedModel, convo:usedConfiguration, convo:invokedTool, convo:requestedBy, convo:hasContributionRole | Connects production activities to models, configurations, tools, requests, and conversational roles. |
This section consolidates the ontology axioms and SHACL contracts that an implementer otherwise would have to reconstruct from several RDF graphs. Cardinalities shown as “base” apply whenever the class is used. Requirements labeled with a profile apply only when that profile is selected. An omitted maximum means that multiple values are permitted.
| Class | Semantic foundation | Structural contract |
|---|---|---|
convo:Conversation | prov:Activity; the interaction, not its stored representation. | Base: at most one closedAt; supplied participations must be Participation values. No contribution or participant is globally required. |
convo:Participation | Qualified context linking an agent to one conversation. | Base: exactly one conversation and one prov:Agent; zero or more roles; at most one beginning and ending. |
convo:ResponsibleParticipation | Participation and prov:Association. | Base: exactly one PROV agent and one associated conversation; conversation, agent, and role values must agree in both vocabularies. |
convo:ParticipantRole | prov:Role. | Controlled role class; no intrinsic cardinality. |
convo:Contribution | prov:Entity; broad informational unit. | Base: no self-reply and at most one authoredAt. Core: at least one conversation; missing content or attribution is a warning unless tombstoned. |
convo:Message | Contribution packaged as a message. | Inherits Contribution; electronic transmission is not implied. |
convo:Utterance | Contribution expressed as an utterance. | Inherits Contribution; message transport is not implied. |
convo:Comment | Message commenting on a resource or selection. | Targeted Comment: at least one qualified target. |
convo:Question | Message requesting information or a decision. | Does not require an answer. |
convo:Answer | Message presented as an answer. | answers values are questions and entail reply edges. |
convo:Reaction | Lightweight Contribution. | Base: exactly one target and at least one reaction type. The occurrence may carry actor, content, time, and lifecycle provenance; it need not be a reply. |
convo:ReactionType | skos:Concept classifying a reaction's communicative kind. | Base: at least one skos:prefLabel; any skos:inScheme value is a skos:ConceptScheme. External platform types are permitted. |
convo:SystemNotice | Operational or moderation Contribution. | System origin is not inferred merely from this type. |
convo:ToolCall | Contribution communicating a tool request. | Agent Execution requires exactly one contribution role on all contributions. |
convo:ToolResult | Contribution carrying a tool result. | Agent Execution: exactly one generating ToolInvocation, which must reciprocally state prov:generated. |
convo:Content | prov:Entity representing payload separately from contribution identity. | No intrinsic cardinality; representation-specific provenance may be attached here. |
convo:Thread | prov:Entity grouping contributions within a conversation. | Base: exactly one conversation. Threaded: at least one contribution, membership consistency, and acyclic replies. |
convo:ConversationRecord | prov:Entity recording or reconstructing an interaction. | Base: exactly one recorded conversation. |
convo:OrderedView | ConversationRecord with contextual membership occurrences. | Transcript: exactly one sequence frame and at least one ordered membership. |
convo:Transcript | Specialized OrderedView. | Inherits record and ordered-view requirements; it is not the conversation itself. |
convo:OrderedMembership | prov:Entity reifying one contribution occurrence in one view. | Transcript: exactly one view, contribution, and locus; contribution must belong to the view's conversation. Position-Aware: locus frame must equal the view frame. |
convo:ContributionSequenceFrame | loc:Frame giving view positions meaning. | Position-Aware: exactly one ord:Ordering context. |
convo:Account | prov:Entity representing a platform identity. | Any representsAgent value must be a prov:Agent; identity with that agent is not implied. |
convo:Addressing | prov:Entity qualifying an intended addressee and role. | Addressed Message: exactly one message, addressee, and addressing role. |
convo:AddressingRole | Controlled value class. | No intrinsic cardinality. |
convo:MessageTransmission | prov:Activity transmitting a contribution. | Addressed Message: exactly one message and one sender typed as a PROV agent or account. |
convo:Delivery | prov:Activity for one recipient-specific attempt or event. | Addressed Message: exactly one transmission and one recipient or destination. |
convo:Target | prov:Entity identifying a resource or selected fragment. | Targeted Comment: exactly one source resource and at most one selector. |
convo:ConversationStatus | Controlled lifecycle value. | Base: exactly one status dimension. |
convo:StatusDimension | Facet separating operational, resolution, and retention meanings. | Controlled value class; dimensions are not mutually collapsed. |
convo:ConversationStatusAssignment | prov:Entity carrying a qualified status assertion. | Base: exactly one conversation or thread and exactly one status; at most one assignment time. |
convo:ModerationAction | prov:Activity applying moderation policy. | No base target cardinality; PROV times must satisfy the instant policy when supplied. |
convo:Tombstone | prov:Entity preserving unavailable identity and topology. | Base: exactly one unavailable contribution; no payload is required. |
convo:ContributionAct | prov:Activity generating contributions. | Provenance-Rich: at least one responsible agent and generated contribution. |
convo:HumanContributionAct | Human-specialized ContributionAct. | Human type does not replace an explicit responsible-agent association. |
convo:Model | prov:Entity used for computation. | Kept distinct from invocation and configuration. |
convo:ModelConfiguration | prov:Entity representing parameters or configuration. | May be shared by multiple invocations. |
convo:ModelInvocation | ContributionAct using a model. | Agent Execution: exactly one model, at least one responsible software agent, and at least one generated contribution. |
convo:Tool | prov:SoftwareAgent. | The tool is the software agent; its invocation is a separate activity. |
convo:ToolInvocation | ContributionAct invoking a tool. | Agent Execution: exactly one tool and request, plus at least one generated ToolResult. |
convo:ContributionRole | Controlled role for agent-oriented message position. | Not an agent, author, participant role, or PROV responsibility relation. |
RDFS domains and ranges are inferential: using a property may cause its subject or object to be typed. They are not input-validation filters. Where a property intentionally has no domain, the table says so explicitly.
| Property | Domain → range | Contract and entailment |
|---|---|---|
convo:hasParticipation / convo:participationIn | Conversation ↔ Participation | OWL inverses. A participation has exactly one conversation under the base shapes. |
convo:hasParticipant | Participation → prov:Agent | Exactly one under the base shapes. |
convo:participationRole | Participation → ParticipantRole | Zero or more; responsible participation must mirror values through prov:hadRole. |
convo:beganAt, convo:endedAt | Participation → xsd:dateTime | At most one each; value must carry a timezone. |
convo:hasThread / convo:threadOfConversation | Conversation ↔ Thread | OWL inverses. Every thread has exactly one conversation. |
convo:hasContribution / convo:contributionOf | Conversation ↔ Contribution | OWL inverses. Multi-conversation membership is allowed; Core requires at least one. |
convo:hasThreadContribution / convo:inThread | Thread ↔ Contribution | OWL inverses. Does not entail a reply edge or order. |
convo:inReplyTo / convo:hasReply | Contribution ↔ Contribution | OWL inverses. Self-replies are invalid; Threaded adds transitive acyclicity. Neither property is transitive. |
convo:answers | Answer → Question | Subproperty of inReplyTo; therefore every answer edge is also a reply edge. |
convo:reactsTo | Reaction → resource | Exactly one under the base reaction shape. Does not entail reply, derivation, or thread membership. |
convo:hasReactionType | Reaction → ReactionType | One or more under the base reaction shape. Multiple exact and semantic classifications may coexist and do not prove an agent's internal state. |
convo:quotes | Contribution → prov:Entity | Subproperty of prov:wasQuotedFrom. |
convo:mentions | Contribution → resource | Reference-like mention without stronger semantics. |
convo:references | Contribution → resource | Subproperty of dcterms:references; does not imply quotation, reply, or derivation. |
| Property | Domain → range | Contract and entailment |
|---|---|---|
convo:hasContent | Contribution → Content | Zero or more representations. Core warns when both content and direct text are absent unless tombstoned. |
convo:text | No domain → literal | May describe a Contribution or Content. Values should be strings or language-tagged strings. |
convo:hasAttachment | Contribution → prov:Entity | Attachment does not imply that the entity is conversational content. |
convo:authoredBy | Contribution → prov:Agent | Subproperty of prov:wasAttributedTo; asserts intellectual responsibility. |
convo:submittedBy | Contribution → resource | May identify agent, account, or service; does not imply authorship. |
convo:recordsConversation | ConversationRecord → Conversation | Exactly one under the base record shape. |
convo:hasOrderedMembership / convo:orderedMembershipOf | OrderedView ↔ OrderedMembership | OWL inverses. Transcript requires at least one occurrence and exactly one view per occurrence. |
convo:membershipContribution | OrderedMembership → Contribution | Exactly one in Transcript; must belong to the view's recorded conversation. |
convo:membershipLocus | OrderedMembership → loc:Locus | Exactly one in Transcript; Position-Aware requires frame agreement. |
convo:hasPositionFrame | OrderedView → loc:Frame | Exactly one ContributionSequenceFrame in Transcript. |
convo:hasGenerationLocus | Contribution → loc:Locus | Optional stable node for qualified or contested generation positions. |
| Property | Domain → range | Contract and entailment |
|---|---|---|
convo:representsAgent | Account → prov:Agent | Representation only; does not assert owl:sameAs. |
convo:hasAddressing / convo:addressingOf | Contribution ↔ Addressing | OWL inverses. Addressed Message narrows the contribution to Message and requires exactly one per Addressing. |
convo:addressee | Addressing → resource | Exactly one in Addressed Message. |
convo:hasAddressingRole | Addressing → AddressingRole | Exactly one in Addressed Message. |
convo:addressedTo | Contribution → resource | Convenience relation; does not entail a qualified Addressing node or delivery. |
convo:hasAudience | Contribution → resource | Intended audience only; does not entail individual addressing or delivery. |
convo:transmitsContribution | MessageTransmission → Contribution | Subproperty of prov:used; Addressed Message requires exactly one Message. |
convo:transmissionSender | MessageTransmission → resource | Exactly one agent or account in Addressed Message; independent of author and submitter. |
convo:hasDelivery / convo:deliveryOf | MessageTransmission ↔ Delivery | OWL inverses. Addressed Message requires exactly one transmission per Delivery. |
convo:deliveryRecipient | Delivery → resource | Exactly one in Addressed Message; does not imply intended addressing. |
convo:discusses | Conversation → resource | Artifact Discussion requires at least one IRI value. |
convo:hasTopic | No domain → resource | May be used on conversations, threads, or contributions. |
convo:hasTarget | Contribution → Target | Targeted Comment requires at least one on every Comment. |
convo:sourceResource | Target → resource | Exactly one in Targeted Comment. |
convo:selector | Target → resource | Optional, at most one in Targeted Comment; syntax comes from an external selector vocabulary. |
convo:targetPurpose | Target → resource | Optional purpose vocabulary; does not change selector meaning. |
| Property | Domain → range | Contract and entailment |
|---|---|---|
convo:hasStatus | No domain → ConversationStatus | May be used on Conversation or Thread. Multiple dimensions and conflicting values may coexist; distinct direct values in one dimension produce a warning. |
convo:hasStatusDimension | ConversationStatus → StatusDimension | Exactly one for every status value. |
convo:statusOf | StatusAssignment → resource | Exactly one Conversation or Thread. |
convo:assignedStatus | StatusAssignment → ConversationStatus | Exactly one. |
convo:revisionOf | prov:Entity → prov:Entity | Subproperty of prov:wasRevisionOf. |
convo:supersedes | prov:Entity → prov:Entity | Replacement only; neither derivation nor identity is entailed. |
convo:alternativeTo | Contribution ↔ Contribution | OWL symmetric; does not entail derivation. |
convo:regenerationOf | Contribution → Contribution | Subproperty of prov:wasDerivedFrom; records a new attempt for substantially the same request or position. |
convo:redactedVersionOf, convo:summaryOf | prov:Entity → prov:Entity | Both entail prov:wasDerivedFrom but retain distinct intent. |
convo:moderates | ModerationAction → resource | Identifies the affected conversational resource. |
convo:tombstoneFor | Tombstone → Contribution | Exactly one; reply edges continue to target the original contribution IRI. |
convo:usedModel | ModelInvocation → Model | Subproperty of prov:used; exactly one in Agent Execution. |
convo:usedConfiguration | ModelInvocation → ModelConfiguration | Subproperty of prov:used; optional and repeatable. |
convo:invokedTool | ToolInvocation → Tool | Subproperty of prov:wasAssociatedWith; exactly one in Agent Execution. |
convo:requestedBy | ToolInvocation → resource | Exactly one in Agent Execution. |
convo:hasContributionRole | Contribution → ContributionRole | Exactly one in Agent Execution; does not establish authorship. |
convo:assignedAt, convo:authoredAt, convo:sentAt, convo:deliveredAt, convo:receivedAt, convo:displayedAt, convo:closedAt | Owning construct → xsd:dateTime | At most one where constrained; every supplied value must be xsd:dateTimeStamp or timezone-bearing xsd:dateTime. |
| Value | Type or dimension | Meaning |
|---|---|---|
convo:ReactionTypes | skos:ConceptScheme | Open built-in semantic pivot scheme. It is not a closed enumeration; external schemes remain conformant. |
convo:Like, convo:Dislike, convo:Love | ReactionType | Positive preference, negative assessment, and strong positive or affectionate response. |
convo:Agree, convo:Disagree, convo:Acknowledge | ReactionType | Concurrence, dissent, and receipt or recognition without necessary agreement. |
convo:Appreciate, convo:Support, convo:Amused, convo:Celebrate | ReactionType | Gratitude, solidarity, amusement, and celebration or congratulations. |
convo:Interested, convo:Confused, convo:Surprised, convo:Concerned | ReactionType | Interest, difficulty understanding, valence-neutral surprise, and concern or caution. |
convo:Sadness, convo:Anger | ReactionType | Communicated sadness or sympathy, and anger or strong objection; neither asserts a private mental state. |
convo:Participant, convo:Moderator, convo:Facilitator | ParticipantRole | Ordinary participation, policy moderation, or guidance of conversational conduct. |
convo:PrimaryRecipient, convo:CopyRecipient, convo:BlindCopyRecipient, convo:AudienceMember | AddressingRole | Direct, visible-copy, confidential-copy, or audience-only addressing. None proves delivery. |
convo:Proposed, convo:Open, convo:Active, convo:Paused, convo:Closed | convo:OperationalStatusDimension | Whether and how ordinary participation is presently accepted or occurring. |
convo:Resolved | convo:ResolutionStatusDimension | The substantive matter is considered resolved; operational closure is not entailed. |
convo:Archived | convo:RetentionStatusDimension | The interaction is retained primarily as an archive; resolution is not entailed. |
convo:UserRole, convo:AssistantRole, convo:SystemRole, convo:ToolRole | ContributionRole | Position in an agent-oriented exchange, not the identity or provenance of its author. |
A conforming RDFS or OWL processor may derive types from domains and ranges, superclass types, superproperty statements, inverse statements, and the symmetry of alternativeTo. Publishers need not materialize those consequences. Consumers that do not run entailment SHOULD use inverse-aware query paths where this specification permits either direction.
| Asserted pattern | Entailed | Not entailed |
|---|---|---|
a answers b | a inReplyTo b; Answer and Question types through domain/range. | Same thread, adjacency, correct answer, or accepted answer. |
conversation hasContribution item | item contributionOf conversation under OWL. | Exclusive membership, a thread, an order, or authorship. |
item inReplyTo parent | parent hasReply item under OWL. | Derivation, generation input, chronological succession, or shared conversation. |
reaction hasReactionType type | Reaction and ReactionType types through domain/range. | One universal emoji meaning, agreement, positive sentiment, or the actor's private emotional state. |
item authoredBy alice | item prov:wasAttributedTo alice. | Alice submitted, transmitted, or delivered the item. |
send transmitsContribution item | send prov:used item. | The sender authored the item or any recipient received it. |
run usedModel model | run prov:used model. | Model identity, configuration, responsible service, or output. |
run invokedTool tool | run prov:wasAssociatedWith tool. | A human requester, successful execution, or a particular result. |
a alternativeTo b | b alternativeTo a. | Derivation, revision, equivalence, or preference. |
a regenerationOf b | a prov:wasDerivedFrom b. | Revision, supersession, or semantic equivalence. |
| An OrderedMembership has locus 3. | A position only when interpreted in the view's frame. | That the Contribution has global index 3 or was third in generation time. |
SHACL validation does not add RDF entailments. A graph can satisfy a profile without storing inferred inverse triples because the shapes use alternative inverse paths. Conversely, passing base shapes does not assert that a graph satisfies any named profile.
The examples below pair legal ontology patterns with superficially similar graphs that violate a selected validation contract. “Invalid” means invalid for the stated profile, not syntactically invalid Turtle.
These examples are intentionally small. They show how orthogonal parts compose without requiring every dataset to use every capability.