Knowledge Processing Model in SimpleModeling
This article concisely defines the transformation from knowledge to execution as the mechanism that projects knowledge into the real world. It proceeds through Embedding, RDF, Type, DSL (Domain Specific Language), Interpreter, and Effect to produce real-world impact, with the entire pipeline cross-cuttingly governed by Context.
Knowledge Processing Model
In SimpleModeling, knowledge is not merely stored information but a target for transformation into executable structure. This model explicitly defines that transformation process.
This figure represents the full structure from knowledge to real-world effects.
Embedding
Embedding represents knowledge as a semantic space, enabling similarity-based discovery.
-
ambiguous meaning
-
similarity search
-
AI-driven exploration
It is realized using vector databases.
RDF
RDF represents knowledge as a graph, making relationships explicit.
-
explicit representation of relationships
-
connection of knowledge
-
structuring
It is implemented using RDF databases or graph databases.
Type
Type fixes meaning into a strict structure and serves as the core of symbol grounding.
-
Entity / Value
-
constraints (invariants)
It is described in CML.
DSL
DSL describes behavior. At this stage, no side effects occur; it represents computation as intent.
-
AST (free structure)
-
function (morphism: Type → Type)
-
procedure (Kleisli morphism: Type → EffectType)
-
operation definitions
-
flows
It is described in CML.
Interpreter
Interpreter assigns meaning to DSL and transforms it into Effects.
-
DSL ⇒ Effect
-
definition of execution strategy
Context
Processing at each layer is affected by the application context.
For example, even for the same user registration process, in a development environment email sending may be replaced with logging, while in production it uses a real email service (e.g., SES). Such behavioral differences are controlled by context. Additionally, in a B2B application, organizationId may be required, while in a personal application it may not, meaning that even the structure of types can vary depending on context.
Context is a cross-cutting element that affects all layers.
Category Theory
By organizing the model from a category-theoretic perspective, we can validate the consistency and simplicity of its structure. In particular, it serves as a guideline to verify the separation of objects and morphisms, the naturalness of composition, and the coherence of transformations.
Modeling with category theory does not provide direct benefits, but it serves as a guiding framework to ensure the model is well-structured.
This model can be understood as a coherent structure in category theory. We describe it in terms of functors, natural transformations, and adjunctions.
Functor
A functor is a structure-preserving mapping between categories. In SimpleModeling, the transformation from the conceptual world to the program world can be seen as a functor.
ConceptWorld → TypeWorldThis functor maps ambiguous meanings (Embedding/RDF) into typed structures.
Free Structure and DSL
DSL can be understood as a free structure. It generates computational structures based on types without imposing additional constraints.
Type → DSL(AST)（Free）
function : Type → Type（Morphism）
procedure : Type → Effect[Type]（Kleisli Morphism）Natural Transformation
Interpreter can be understood as a natural transformation from DSL to Effect.
Interpreter : DSL ⇒ EffectA natural transformation assigns meaning while preserving structure.
Effect and Evaluation
Effect represents unevaluated computation. Interaction with the real world occurs only through evaluation (run).
Effect --run--> RealityAdjunction
Adjunction is the optimal correspondence between adding structure and forgetting structure.
F : Concept → Program
G : Program → Concept
F ⊣ GHere:
Unit and Counit
Adjunctions come with two natural transformations.
η : Id ⇒ G ∘ F （unit）
ε : F ∘ G ⇒ Id （counit）These guarantee round-trip consistency between meaning and structure.
Context as Parameter
Context can be understood as a parameter that determines natural transformations.
Context → (DSL ⇒ Effect)In other words, different interpreters (natural transformations) are selected depending on context.
Correspondence
This section summarizes the correspondence of each element.
-
Concept: domain of meaning and knowledge
-
Type: structured objects
-
DSL: morphisms and their composition
-
AST: syntax of DSL (free structure)
-
function: pure morphism (Type → Type)
-
procedure: Kleisli morphism with effects (Type → EffectType)
-
Interpreter: natural transformation (DSL ⇒ Effect)
-
Effect: evaluable computation
-
Reality: evaluated result in the real world
-
Context: meta-layer controlling interpretation
This model can be summarized as the following categorical correspondence:
Context acts as a meta-layer over the entire structure.
This structure allows SimpleModeling to handle the transformation from meaning to execution in a theoretically consistent manner.
Category theory is not required for implementation, but the ability to describe the model naturally in these terms is a strong indicator that the structure is simple and coherent.
Summary
The SimpleModeling knowledge processing model is a unified transformation system from meaning (Embedding/RDF) to structure (Type), then to computation (DSL), and finally to execution (Interpreter/Effect).
In this model, Types fix meaning as objects, while DSL composes computations as morphisms. The Interpreter, as a natural transformation, assigns semantics to DSL and transforms it into executable Effects.
Only through the evaluation (run) of Effects do real-world actions occur.
Context operates across the entire system, determining interpretation and execution at every layer.
This structure enables SimpleModeling to treat knowledge not merely as description, but as a structured, composable, and executable model.
References
Glossary
- RDF
-
A W3C-standardized data model that represents information as subject–predicate–object triples.
- DSL (Domain Specific Language)
-
A DSL (Domain-Specific Language) is a language designed for a particular domain, enabling direct and concise expression of the domain’s concepts and structures. Compared to general-purpose programming languages (GPLs), DSLs offer a higher level of abstraction tailored for domain-specific problem solving and automation.
- type safety
-
Type safety refers to the property of a programming language or system where operations are guaranteed to be used with values of the correct type. Type-safe code prevents invalid operations by detecting type mismatches at compile time (or runtime), reducing runtime errors and unexpected behaviors. Scala ensures type safety through strong static typing combined with type inference, enabling expressive yet safe programming.
- CML (Cozy Modeling Language)
-
CML is a literate modeling language for describing Cozy models. It is designed as a domain-specific language (DSL) that forms the core of analysis modeling in SimpleModeling. CML allows model elements and their relationships to be described in a narrative style close to natural language, ensuring strong compatibility with AI support and automated generation. Literate models written in CML function as intermediate representations that can be transformed into design models, program code, or technical documentation.
- Competency
-
A human capability required to perform certain Activities effectively. Competencies define skills, experience, and knowledge levels associated with roles.