Conceptual Semantics [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Conceptual Semantics ======

[[dido:99_annexes:annex-b-terms-and-definitions:start|Go up to Terms and Definitions]]

===== Discussion =====

Conceptual semantics defines meaning at the level of domain concepts, relationships, distinctions, and constraints before an architecture selects implementation technology.

Conceptual semantics establishes domain meaning independently of [[dido:99_annexes:annex-b-terms-and-definitions:s:schema|schemas]], databases, programming languages, [[dido:99_annexes:annex-b-terms-and-definitions:r:rdf_graph|RDF graphs]], [[dido:99_annexes:annex-b-terms-and-definitions:o:owl|OWL]] [[dido:99_annexes:annex-b-terms-and-definitions:o:ontology|ontologies]], message formats, [[dido:99_annexes:annex-b-terms-and-definitions:a:api|APIs]], [[dido:99_annexes:annex-b-terms-and-definitions:r:report|reports]], or runtime logic. A [[dido:99_annexes:annex-b-terms-and-definitions:c:conceptual_model|conceptual model]] expresses conceptual semantics when it identifies the things in a domain, the relationships among those things, the distinctions that matter, and the constraints that govern interpretation.

Conceptual semantic content includes:

  * Domain concepts
  * Business terms
  * Relationships among concepts
  * Roles played by participants
  * Classifications and distinctions
  * Constraints on valid meaning
  * Lifecycle states
  * Events and state transitions
  * Business rules
  * Reporting facts and dimensions
  * Policies and governance concepts
  * Domain assumptions

A governed architecture preserves [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] from conceptual semantics to downstream artifacts. Traceability prevents implementation artifacts from replacing the intended domain meaning.

===== Definition =====

//meaning defined through domain concepts, relationships, distinctions, and constraints before selection of implementation technology//

===== Source =====

DIDO Solutions usage, informed by conceptual modeling, terminology practice, semantic modeling practice, and model-driven architecture principles.

===== Note =====

Conceptual semantics is not equivalent to [[dido:99_annexes:annex-b-terms-and-definitions:o:owl|OWL]], [[dido:99_annexes:annex-b-terms-and-definitions:r:rdf|RDF]], [[dido:99_annexes:annex-b-terms-and-definitions:r:rdf_graph|RDF graph]] structure, [[dido:99_annexes:annex-b-terms-and-definitions:s:schema|schema]] structure, [[dido:99_annexes:annex-b-terms-and-definitions:d:datatype|datatype]] structure, or implementation logic. Those artifacts express selected conceptual meaning after the architecture establishes the underlying domain meaning.

===== Example =====

An FX conceptual model defines concepts such as ''Trade'', ''Counterparty'', ''Currency Pair'', ''Notional Amount'', ''Trade Date'', ''Settlement Date'', and ''Settlement Obligation''. These concepts establish conceptual semantics before the architecture represents selected content in schemas, reports, RDF graphs, OWL ontologies, DDS topics, databases, or executable validation logic.

----

<WRAP centeralign>
© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
</WRAP>