Typed Ontology Knowledge Graph

Problem Addressed

When multiple agents or skills need shared state, plain Markdown notes make it hard to express object types, relation constraints, and dependency queries. ontology1111111 models knowledge as a typed entity graph, suited to questions like “what do I know about X”, “what depends on X”, or “how should this multi-step plan change?” It is useful when verifiable shared memory is needed, not just text summaries.

How It Works

The skill treats everything as an entity with type, properties, and relations. Before creating, updating, or linking, it validates constraints from memory/ontology/schema.yaml, including property checks, enums, forbidden values, relation types, cardinality, acyclicity, and event time intervals. The default store is memory/ontology/graph.jsonl, and changes follow an append-only / merge policy to avoid clobbering existing definitions.

Key steps include:
- Create Entity: write typed objects such as tasks, projects, dependencies, or external resources.
- Query: traverse the graph by entity, property, or relation.
- Link Entities: create an X -> Y relation and validate its constraints.
- Validate: check graph state before commit, then rollback or reject invalid changes.

Multi-step plans are modeled as a sequence of graph transformations, with each step validated before execution.

Boundaries

It is not a general-purpose database and does not provide vector search, access control, or remote service orchestration. For larger graphs or complex queries, the materials suggest migrating to SQLite. Some higher-level constraints may remain documentation-only unless implemented in code. It fits local workspace state, cross-skill coordination, and dependency reasoning.