Built-in Relations

Relation Properties

Each relation may have the following mathematical properties:

Taxonomic Relations

Relations for organizing concepts into hierarchies:

Examples

# Taxonomy assertions
@f1 ASSERT Dog IS_A mammal
@f2 ASSERT mammal IS_A animal
@f3 ASSERT Cat IS_A mammal
@f4 ASSERT Dog DISJOINT_WITH Cat

# Query with transitive closure
@q1 ASK Dog IS_A animal        # TRUE (via transitivity)
@q2 ASK Dog DISJOINT_WITH Cat  # TRUE

Mereological Relations (Part-Whole)

Relations for compositional structure:

Examples

# Mereological structure
@f1 ASSERT Engine PART_OF Car
@f2 ASSERT Piston PART_OF Engine

# Query transitivity
@q1 ASK Piston PART_OF Car     # TRUE (via Engine)

Spatial Relations

Relations for location and containment:

Examples

# Spatial assertions
@f1 ASSERT Paris LOCATED_IN France
@f2 ASSERT France LOCATED_IN Europe

# Spatial query
@q1 ASK Paris LOCATED_IN Europe  # May require explicit rule

Causal Relations

Relations for cause-effect reasoning:

Examples

# Causal assertions
@f1 ASSERT Fire CAUSES Smoke
@f2 ASSERT Rain CAUSES WetGround

# Abductive reasoning (find causes)
@causes ABDUCT Smoke CAUSED_BY
# Returns: [Fire, ...]

Deontic Relations (Norms)

Relations for permissions, prohibitions, and compliance:

Examples

# Normative assertions
@f1 ASSERT GDPR PERMITS ConsentBasedProcessing
@f2 ASSERT GDPR PROHIBITS UnconsentedDataSale
@f3 ASSERT OurSystem COMPLIES_WITH GDPR

# Compliance check
@q1 ASK OurSystem VIOLATES GDPR  # Should be FALSE

Domain-Specific Relations

Pre-defined relations for specific use cases:

Healthcare

Narrative

Relation Constraints

Relations can have constraints that enforce logical consistency:

Functional Relations

A relation is functional if each subject can have at most one object:

# Declare BORN_IN as functional (one value only)
@_ REGISTER_FUNCTIONAL BORN_IN

# This is valid:
@f1 ASSERT Alice BORN_IN Paris

# This would cause a FUNCTIONAL_VIOLATION:
@f2 ASSERT Alice BORN_IN London  # Contradiction!

Cardinality Constraints

Limit how many relations of a type an entity can have:

# Person can have 0-2 biological parents
@_ REGISTER_CARDINALITY Person HAS_BIOLOGICAL_PARENT 0 2

# This is valid:
@f1 ASSERT Alice HAS_BIOLOGICAL_PARENT Bob
@f2 ASSERT Alice HAS_BIOLOGICAL_PARENT Carol

# This would cause a CARDINALITY_MAX_VIOLATION:
@f3 ASSERT Alice HAS_BIOLOGICAL_PARENT Dave  # Third parent!

Checking for Violations

# Check all facts for constraint violations
@report CHECK_CONTRADICTION

# Test before adding a fact
@test CHECK_WOULD_CONTRADICT Alice BORN_IN London
# Returns: { wouldContradict: true, reason: "FUNCTIONAL_VIOLATION" }

Relation Encoding

Each relation is implemented as a deterministic permutation of vector dimensions:

encode(A REL B) = permute(encode(A), π_REL) ⊕ encode(B)

Where:

• π_REL is a unique permutation derived from the relation name and seed
• ⊕ is saturating addition (clamped to [-127, 127])

This encoding ensures:

• Uniqueness: Different relations produce different encodings
• Determinism: Same input always produces same output
• Reversibility: Can query for unknown subjects/objects

Technical References

• DS(/core/relation_permuter.js) – Permutation implementation
• Custom Verbs – Defining new relations
• Wiki: Permutation-Based Binding