This page is a “Wikipedia-style” introduction to the design stance behind AGISystem2:
Meaning is not a single fixed object. In practice, texts are used for different tasks (predict, explain, prove, design, critique, teach). AGISystem2 aims to formalize natural language into a DSL so those uses become explicit, testable, and composable.
1) The Problem: One Text, Many Uses
Scientific and technical writing mixes multiple layers:
- Definitions (“X is defined as …”)
- Claims (“X causes Y under conditions C”)
- Models (variables, constraints, invariants)
- Method (procedures, protocols, evaluation)
- Norms (“should”, “must”, “safe”, “allowed”)
- Perspective (assumptions, scope, idealizations)
A system that tries to map all of this into one universal semantics tends to fail on either usability (too rigid) or truthfulness (silently invents meaning). AGISystem2 treats meaning as a set of pragmatic contracts that can coexist.
2) Formal Semantics vs. Formal Pragmatics
Working distinction:
- Formal semantics asks: “Given an expression, what is its truth-conditional content?”
- Formal pragmatics asks: “Given a context and a goal, how should an expression be used?”
AGISystem2’s DSL can host both:
- Truth-conditional fragments (e.g., relations and rules)
- Contextual/operational fragments (defaults, exceptions, priorities, constraints, and evaluation modes)
3) A Quick Map of “Formal Meaning” Traditions
This is not a literature survey; it is a practical map of approaches people use when they say “formal meaning”.
Model-Theoretic
Meaning as truth conditions in a model (classical logic, Montague-style compositional semantics).
Dynamic
Meaning as context update (DRT, file change semantics; anaphora and discourse are first-class).
Type-Theoretic
Meaning via types and dependent structure (type theory / proof assistants; “programs as proofs”).
Proof-Theoretic
Meaning via inference rules and proofs (what you can derive matters as much as what is true).
Situation / Event
Meaning grounded in situations and events (neo-Davidsonian event semantics, situation semantics).
Probabilistic
Meaning with uncertainty (probabilistic logic, Bayesian semantics, probabilistic programming).
Graph / Ontology
Meaning via structured schemas (knowledge graphs, RDF/OWL / description logics, constraint models).
Distributional / Vector
Meaning via similarity in a vector space (distributional semantics, VSA/HDC as structured vectors).
4) Related Attempts “in the Wild”
- Semantic parsing into logical forms, graphs, or programs (often task-specific).
- Controlled natural languages that restrict English to reduce ambiguity.
- Ontology engineering and knowledge graphs (explicit schemas; hard but interoperable).
- Proof assistants (strong guarantees; high authoring cost; limited NL interface).
- Executable specs (constraints, tests, simulators; “meaning” as behavior).
AGISystem2 borrows from all of these, but keeps a pragmatic constraint: the same theory should remain useful even when only partially formalized.
5) What AGISystem2 Builds (Pragmatic Contracts)
AGISystem2 focuses on a small set of repeatable, inspectable contracts:
- Learn: accept DSL statements and track what was added.
- Query: retrieve bindings and candidates; rank and explain.
- Prove: attempt derivations under explicit settings (e.g., closed-world assumption).
- Constraints: encode incompatibilities and invariants; detect contradictions.
- Strategy selection: run the same theory under multiple representation backends and compare behavior.
Design stance: We intentionally avoid claiming a single “final meaning”. Instead we aim for a system that is useful for engineering and science: modular theories, explicit assumptions, reproducible runs, and measurable evaluation.
6) Research Topics & Current Status
Active areas in the project include:
- DSL design for theory modularity, constraints, and transparent loading.
- Reasoning profiles (symbolic vs. holographic priorities) and hybrid pipelines.
- Representation strategies (dense, sparse, metric, elastic, exact) under shared APIs.
- Evaluation suites for translation quality, query quality, and saturation behavior.
- Traceability: explanations, debugging hooks, and failure diagnosis.
Project status is “research-engineering”: the system is usable and test-driven, but still evolving. The intent is to keep the platform honest—what works is measured, what fails is surfaced, and improvements are integrated incrementally.
Further Reading