TaxisBase: The Database of TaxisDB

Overview

TaxisBase is an open collaborative knowledge base containing a core system bootstrap ontology, extensible type system, semantic relationships, constraints, domain/range definitions, and asserted atomic facts for entity types and instances.

TaxisBase defines the canonical knowledge model used by TaxisDB, including the TBox/ABox structure, multidimensional data organization, indexing model, temporal semantics, and database structures.

Core Architecture: TBox and ABox

TaxisBase separates schema from data using the classic description-logic distinction:

• TBox (Terminological Box) — the schema layer. It holds the definitions of types, attributes, value types, enumerations, and composite value types. TBox entities are identified by small sequential integer entity IDs, for example 210 for sys.attr.key or 123 for sys.val.string.
• ABox (Assertional Box) — the data layer. It holds instances (objects, association records) described using the vocabulary defined in the TBox. ABox entities are identified by KSUID-style string entity IDs (e.g. 65710bddc57dczsmgotm), which are globally unique, sortable, and independent of the TBox integer ID space.

The TBox is bootstrapped once, from bootstrap.m, into a local MD array that is subsequently merged into the persistent ^TBox global. Everything else, every attribute, type, and value the system understands about itself is built on top of this bootstrap set.

The Entity-Attribute-Value (EAV) Model

TaxisBase represents all knowledge, both schema and data, as triplets: (Entity, Attribute, Value).

During bootstrap, definitions are staged in a local array shaped as:

MD(Ent, Attr) = Value

where Ent is the numeric entity ID of the concept being defined, and Attr is the numeric ID of a metadata attribute describing some facet of that concept. The same small set of metadata attribute IDs is reused across every kind of TBox entity — value types, attributes, enumerations, composite value types, and abstract types, — which is what makes the bootstrap file self-describing.

API Usage Guide ABox / TBox

For more information and details, read the ABOX - Data Access API User Guide and TBOX - Data Access API User Guide.

TaxisBase Meta-Type System

An entity can be associated with one or more types through the Object type, depending on the roles or aspects it represents. This allows TaxisBase to model the multifaceted nature of a real-world entity without forcing it into a single flat record.

For example, Tom Hanks Object can simultaneously be associated with types such as person, actor, and film producer. Each type contributes its own set of attributes to the same underlying entity.

Not a Programming-Language Type

The term “type” in TaxisBase does not have the strict meaning associated with a programming-language type, where a type typically defines a structural contract enforced by a compiler or runtime.

Instead, a TaxisBase type is closer to the notion of a type in Datomic. It is a lightweight, convention-based grouping built on top of namespaced attribute keys rather than a rigid class, struct, or schema object.

For example, the attributes under:

sandbox.movie.*

can be understood collectively as the attributes belonging to the sandbox.movie type.

The type itself does not define a closed structural contract. The semantics of individual attributes are defined by their own metadata, including properties such as:

• Range
• Cardinality
• Uniqueness
• Required-ness

Entities are therefore described incrementally, attribute by attribute. An entity does not need to conform to one complete type definition and can acquire attributes from multiple types simultaneously through multiple associations.

The TaxisBase type system is consequently best understood as an organizing and semantic layer over the EAV model. It provides a vocabulary for grouping, describing, and discovering related attributes without imposing the closed structural model typically associated with classes or records in programming languages.

The System Type Hierarchy

At the root of the sys.type namespace hierarchy are seven system types. These types are themselves instances of sys.type.type and form the foundational vocabulary from which the rest of the TaxisBase type system is generated.

EID	Key	Abbreviation	Purpose
100	sys.type.val	DTYPE	Atomic data types that define the range of attributes.
200	sys.type.attr	ATYPE	Properties and characteristics that can be assigned to entities.
300	sys.type.enum	ENUM	Enumerated value types representing closed sets of named constants.
500	sys.type.cvt	CVT	Composite value types that capture several related fields as a single structured value.
700	sys.type.type	TYPE	Foundational entity types that form the cornerstone of the type system.
800	sys.type.assoc	ASSOC	Relationship types that describe objects from a particular perspective, analogous to relations in the Relational Model.
900	sys.type.obj	OBJ	Objects representing specific instances of topics in TaxisBase.

These types provide distinct roles within the meta-type system:

• sys.type.val defines atomic data types used as attribute ranges.
• sys.type.enum defines closed sets of named values.
• sys.type.cvt defines structured values composed of multiple fields that are captured together as a single value.
• sys.type.assoc defines relationships through which an object can be described from a particular perspective or role, such as person, pianist, or film actor.
• sys.type.type defines the types themselves, allowing the type system to describe and extend itself.
• sys.type.attr defines the properties and characteristics that can be assigned to entities.
• sys.type.obj represents the concrete objects that populate the TaxisBase model.

Together, these seven system types form the bootstrap vocabulary of TaxisBase. They provide the primitives from which application-specific types, attributes, values, enumerations, composite values, associations, and objects can be defined.

Value Types

It does not answer what the entity means or how many values an attribute may have.

Every attribute has exactly one value type, declared through sys.attr.range. The value type determines the representation and validation rules for the attribute’s values.

TaxisBase organizes value types into three of the seven system types:

• Atomic Value Types (sys.type.val, DTYPE): a single indivisible value, such as sys.val.string, sys.val.integer, sys.val.date, or sys.val.ref.
• Enumerated Value Types (sys.type.enum, ENUM): a closed set of named instances that constrains an attribute to a defined vocabulary, such as sys.enum.cardinality with the instances one and many.
• Composite Value Types (sys.type.cvt, CVT): multiple interrelated fields captured together as one structured value, such as sys.cvt.geo, which groups geographic representations such as latitude, longitude, and altitude.

Atomic Value Types

Atomic value types represent individual, indivisible values.

EID	Key	Abbr	Description
120	sys.val.ref	REF	Reference to another object.
121	sys.val.keyword	KEYWORD	Unique human-readable identifier.
122	sys.val.integer	INT	64-bit signed integer.
123	sys.val.string	STRING	Textual data.
124	sys.val.boolean	BOOLEAN	Boolean value represented as 0 = false, 100 = true.
125	sys.val.timestamp	TIMESTAMP	Microseconds since 1970-01-01 UTC.
156	sys.val.uuid4	UUID4	UUID version 4.
157	sys.val.double	DOUBLE	Double-precision floating-point value.
159	sys.val.url	URL	URL.
160	sys.val.name	NAME	Short, human-readable identifier of an entity.
181	sys.val.date	DATE	ISO-8601 date, for example 2026-05-07.
182	sys.val.time	TIME	ISO-8601 time, for example 18:46:25.
184	sys.val.datetime	DATETIME	ISO-8601 datetime, for example 2026-05-07T18:46:25.410423+02:00.
185	sys.val.point	POINT	WKT POINT (lon lat).
186	sys.val.pointz	POINTZ	WKT POINT Z (lon lat alt).
190	sys.val.alias	ALIAS	Alternative, memorable reference to the same entity.
192	sys.val.langstr	LANGSTR	String with a mandatory @<lang> suffix.
193	sys.val.geohash	GEOHASH	Geohash encoding of a position.
194	sys.val.gps	GPS	(lat, lng) in decimal degrees using WGS84.

Enumerated Value Types

An enumerated value type defines a closed set of named instances. It is conceptually similar to a lookup table in a relational database, but the enumeration itself is part of the TaxisBase model.

For example:

YDB>D PEs^sapi("sys.enum",1)

 310  sys.attr.key             sys.enum.cardinality
 317  sys.attr.key             sys.enum.cardinality.many
 311  sys.attr.key             sys.enum.cardinality.one
 380  sys.attr.key             sys.enum.unique
 383  sys.attr.key             sys.enum.unique.insert
 385  sys.attr.key             sys.enum.unique.upsert

eid	Key	Instances
310	sys.enum.cardinality	sys.enum.cardinality.one (311), sys.enum.cardinality.many (317)
380	sys.enum.unique	sys.enum.unique.insert (383), sys.enum.unique.upsert (385)

Two examples are:

• Cardinality: one restricts an attribute to a single value; many allows multiple values.
• Uniqueness: insert enforces uniqueness when inserting a value and rejects duplicates; upsert uses identity-based upsert semantics, associating incoming data with the existing entity that owns a matching value rather than rejecting it.

Composite Value Types

A composite value type, or CVT, groups several interrelated fields that must be captured together as a single structured value rather than as independent attributes.

This is comparable in concept to a Freebase Compound Value Type.

For example:

YDB>D PEs^sapi("sys.cvt",1)

 510  sys.attr.key             sys.cvt.geo
1004  sys.attr.key             sys.cvt.geo.geohash
1003  sys.attr.key             sys.cvt.geo.gps
1000  sys.attr.key             sys.cvt.geo.longitude
1001  sys.attr.key             sys.cvt.geo.point
1002  sys.attr.key             sys.cvt.geo.pointz

Here, sys.cvt.geo groups several related geographic representations into a single composite value.

Value Types vs. Attributes

A value type and an attribute answer different questions.

An attribute has a value type. It is not itself a value type.

For example:

sandbox.movie.title
        │
        └── range → sys.val.string

sandbox.movie.title is an attribute whose range is sys.val.string. The same value type can be used by many unrelated attributes:

sandbox.movie.title  → sys.val.string
sandbox.person.name  → sys.val.string
sandbox.movie.plot   → sys.val.string

sys.val.string defines the shape and representation of the value, but carries no domain-specific meaning. The attribute supplies that meaning.

This separation allows a single value type to be reused throughout the schema while each attribute independently defines its own semantics, constraints, cardinality, uniqueness, and other properties.

Value Key Encoding (^TBD / ^TBDR)

Because a value type can be shared by many unrelated attributes, TaxisBase does not store literal values directly under the value type.

Instead, each attribute maintains its own private vocabulary of values. Values are assigned compact, deterministic value keys (valkey) rather than using the literal value directly as a database subscript.

The value-key format is:

K<3-hex-char attribute ID>.<6-hex-char monotonic counter>

For example:

K10B.01882E

represents a value belonging to attribute 267 (0x10B) with sequence 0x1882E.

The counter is global across all attributes and is incremented once for each newly registered value.

This encoding keeps subscript ordering deterministic and independent of the host database’s numeric-coercion rules.

Two globals implement the value vocabulary:

• ^TBD(aid,valkey) is the forward index, resolving a value key to its literal value or, for reference-valued attributes, to the referenced entity ID.
• ^TBDR(aid,val) is the reverse index, resolving a literal value or entity ID to its value key.

Per-Attribute Value Vocabularies

The value dictionary is scoped by attribute ID rather than shared across an entire value type.

This distinction is important because two attributes can use the same value type while having completely different semantic constraints.

For example:

sandbox.movie.imdbid  → sys.val.string
sandbox.person.ssn    → sys.val.string

Both attributes accept strings, but their values belong to separate attribute-specific vocabularies.

This makes several operations naturally attribute-specific:

• Uniqueness enforcement
• Value indexing through ^TBAVET
• Reverse lookups
• Attribute-level validation
• UNQINSERT and UNQUPSERT semantics

Consequently, values belonging to sandbox.movie.imdbid cannot collide with or leak into the value space of sandbox.person.ssn, even though both attributes use the same sys.val.string value type.

The value type defines the shape of the data. The attribute defines its meaning and constraints. The attribute-specific value vocabulary provides the concrete set of values registered for that attribute.

Attributes

Attribute Type (ATYPE)

In the meta-type system, sys.type.attr is the system type whose instances represent properties or characteristics that can be assigned to objects.

Every attribute in TaxisBase is an instance of sys.type.attr. This includes both system attributes, such as sys.attr.key, and domain attributes, such as sandbox.movie.title.

The attributes therefore share the same type. What distinguishes one attribute from another is the metadata asserted about the attribute, including its range, cardinality, uniqueness, required-ness, validation rules, and other characteristics.

Conceptually:

sys.type.attr
     │
     ├── sys.attr.key
     ├── sys.attr.range
     ├── sys.attr.cardinality
     │
     ├── sandbox.movie.title
     ├── sandbox.movie.release_date
     └── sandbox.person.name

The attribute’s name identifies the property, while its metadata defines how that property behaves.

An Attribute Is an Entity

An attribute is itself a first-class entity in TaxisBase. It is an instance of sys.type.attr and is described through a set of core metadata attributes.

The following are the core attributes used to describe attributes:

YDB>D Print^keywords("sys.attr")

KEYWORD                            ALIAS
-----------------------------------------------------------------
sys.attr.abbr                      abbr
sys.attr.alias                     alias
sys.attr.cardinality               cardin
sys.attr.description               doc
sys.attr.display                   display
sys.attr.ensure                    ensure
sys.attr.entattributes             entattrs
sys.attr.entvalidation             entvalid
sys.attr.example                   eg
sys.attr.exptype                   exptype
sys.attr.extid.code                code
sys.attr.homepage                  home
sys.attr.id                        id
sys.attr.indexed                   ndx
sys.attr.isa                       isa
sys.attr.key                       key
sys.attr.label                     label
sys.attr.name                      name
sys.attr.notes                     notes
sys.attr.range                     range
sys.attr.required                  req
sys.attr.resolvedby                rby
sys.attr.unique                    unq
sys.attr.usage                     use
sys.attr.validation                valid
sys.attr.wikipage                  wiki

These metadata attributes describe both the semantic meaning of an attribute and the rules governing its use.

For example, an attribute such as:

sandbox.movie.title

can be described by assertions about:

range       → sys.val.string
cardinality → sys.enum.cardinality.one
required    → true
unique      → ...
description → ...

The attribute is therefore not merely a name or a column definition. It is an entity with its own identity, metadata, and behavior within the TaxisBase model.

This is a direct consequence of the reflective design of TaxisBase: the same fact-oriented mechanisms used to describe application entities are also used to describe the attributes that define those entities.

Referential Integrity Constrains

Defining a new attribute requires, at minimum, four core metadata attributes:

• sys.attr.key: the unique dot-notated identifier of the attribute.
• sys.attr.range: the value type to which its values must conform.
• sys.attr.cardinality: whether the attribute accepts one value or many values.
• sys.attr.isa: identifies the attribute as an instance of sys.type.attr (ATYPE).

These four metadata attributes are themselves marked as required through sys.attr.required=1. Every new attribute definition must therefore supply them.

An attribute may also define additional constraints and behavior, including:

• sys.attr.unique: uniqueness semantics, such as insert or upsert.
• sys.attr.required: whether the attribute itself is required when describing an entity.
• sys.attr.validation: a fully qualified predicate function invoked when a value is asserted.
• sys.attr.exptype: the expected type of an entity referenced by a reference-valued attribute.
• sys.attr.ensure: entity-level validation invoked when facts about an entity are asserted.
• sys.attr.entattributes: attributes that an entity is required to possess.
• sys.attr.entvalidation: predicates that validate the entity as a whole.

range vs exptype vs domain

These three concepts describe different levels of constraint and should not be conflated.

TaxisBase’s definition of sys.attr.exptype explicitly distinguishes range from domain:

range, what kind of value

sys.attr.range defines the value type to which an attribute’s values must conform.

For example:

sandbox.movie.title → sys.val.string
sandbox.movie.year  → sys.val.integer
sandbox.movie.date  → sys.val.date
sandbox.movie.genre → sys.val.ref

The range describes the shape of the value. It does not describe the semantic role of the attribute or, when the range is sys.val.ref, the type of entity being referenced.

A range of sys.val.ref means only that the value is an entity reference. By itself, it does not restrict which entity the reference may identify.

domain, which entity the attribute belongs to

The domain of an attribute identifies the kind of entity that the attribute describes.

TaxisBase does not represent this relationship through a dedicated sys.attr.domain metadata attribute. Instead, domain is expressed implicitly through the attribute’s namespace.

For example:

sandbox.movie.title
sandbox.movie.release_date
sandbox.movie.director

all belong to the sandbox.movie namespace and therefore describe the sandbox.movie type.

Similarly:

sandbox.person.name
sandbox.person.birth_date

belong to the sandbox.person namespace.

The namespace segment of the attribute key therefore acts as the domain declaration. There is no separate sys.attr.domain attribute in the core metadata vocabulary.

exptype - What Must a Reference Point To ?

sys.attr.exptype applies when an attribute has sys.val.ref as its range.

A reference-valued range establishes only that the value identifies another entity:

sys.attr.range → sys.val.ref

It does not specify what kind of entity that reference must identify.

sys.attr.exptype provides that additional restriction:

sys.attr.range   → sys.val.ref
sys.attr.exptype → some entity type

For example, sys.attr.cardinality has the following definition:

YDB>D PE^sapi(cardin)

======
sys.attr.cardinality
======
 241  sys.attr.key             sys.attr.cardinality
 241  sys.attr.range           sys.val.ref
 241  sys.attr.required        1
 241  sys.attr.label           Cardinality @en
 241  sys.attr.cardinality     sys.enum.cardinality.one
 241  sys.attr.name            cardinality
 241  sys.attr.alias           cardin
 241  sys.attr.description     Enumerated single-value attribute that defines whether another attribute holds one or many values @en
 241  sys.attr.extid.code      :db/cardinality
 241  sys.attr.exptype         sys.enum.cardinality
 241  sys.attr.isa             sys.type.attr

The important assertions are:

range   → sys.val.ref
exptype → sys.enum.cardinality

Together they mean that a value of sys.attr.cardinality must be an entity reference, and that the referenced entity must be an instance of sys.enum.cardinality.

Therefore, valid values include:

sys.enum.cardinality.one
sys.enum.cardinality.many

but an arbitrary entity elsewhere in the database is not valid.

Without exptype, the declaration:

sys.attr.range → sys.val.ref

would permit the attribute to reference any entity.

The distinction is therefore:

domain
  │
  └── Which entities may carry this attribute?
      Determined by the attribute namespace.

range
  │
  └── What kind of value may the attribute contain?
      Determined by sys.attr.range.

exptype
  │
  └── If that value is a reference, what type must it reference?
      Determined by sys.attr.exptype.

Entity-Level Validation

sys.attr.validation operates at the individual value level. It answers:

Is this value valid for this attribute?

TaxisBase also provides a separate mechanism for validating an entity as a whole. Three metadata attributes work together for this purpose:

Key	EID	Purpose
sys.attr.ensure	201	Enables entity-level validation when facts about an entity are asserted.
sys.attr.entattributes	202	Specifies attributes that the entity must possess.
sys.attr.entvalidation	203	Specifies fully qualified predicate functions that validate the entity as a whole.

The roles of these attributes are complementary.

sys.attr.entattributes defines structural requirements:

An entity of this type must have attributes A, B, and C.

sys.attr.entvalidation defines semantic or cross-attribute requirements:

The combination of attributes A, B, and C must satisfy predicate P.

sys.attr.ensure connects these rules to the assertion pipeline. When a fact about an entity is asserted, ensure causes the configured entity-level checks to be evaluated.

The distinction between value-level and entity-level validation is therefore:

Validation	Scope	Mechanism
Value validation	One value on one attribute	sys.attr.validation
Required attributes	Entity structure	sys.attr.entattributes
Entity validation	Complete entity	sys.attr.entvalidation
Validation trigger	Assertion pipeline	sys.attr.ensure

This gives TaxisBase two complementary levels of constraint enforcement. Individual values can be validated according to their attribute definitions, while the entity as a whole can be validated against structural and cross-attribute rules.

Descriptive Attributes

Alongside the structural metadata attributes that define how an entity behaves, such as key, range, cardinality, unique, and isa, TaxisBase provides a separate family of descriptive attributes.

Descriptive attributes do not define constraints and do not directly affect validation or indexing behavior. Their purpose is to make an entity understandable, presentable, and discoverable to human users and downstream applications.

Removing a descriptive attribute does not change the structural behavior of the schema.

Key	Alias	Cardinality	Purpose
sys.attr.name	name	one	Short identifier forming the final segment of an entity’s key.
sys.attr.label	label	many	Canonical human-readable display name, typically language-tagged, such as Tom Hanks @en.
sys.attr.abbr	abbr	many	Short, well-known abbreviation, such as STRING for sys.val.string.
sys.attr.description	doc	many	General-purpose, language-tagged explanation of what the entity is.
sys.attr.usage	use	many	Prescriptive guidance describing when and why the entity should be used.
sys.attr.example	eg	many	Representative examples, conventionally prefixed with e.g..
sys.attr.display	display	many	Generic human-readable preview value, not language-tagged, useful for representations such as composite value summaries.
sys.attr.notes	notes	many	Supplemental remarks, including implementation details, caveats, or historical context.

Special Identity Attributes

Two attributes have special identity semantics:

• sys.attr.id
• sys.attr.resolvedby

These attributes identify the target entity of an Assert or Retract operation.

Unlike ordinary attributes, they are not registered in the value dictionary. No value key is allocated for them, and no corresponding entry is created in ^TBD or ^TBDR.

They therefore participate in entity identification at the assertion layer rather than behaving as ordinary fact-bearing attributes.

Example: Defining the sandbox.movie Schema

The following defines two attributes belonging to the sandbox.movie namespace:

S Movie(1,key)="sandbox.movie.title"
S Movie(1,range)=STRING
S Movie(1,cardin)=ONE
S Movie(1,isa)=ATYPE
S Movie(1,doc)="The title of the movie @en"
S Movie(1,req)=1
S Movie(1,valid)="$$IsLangStr^utils"
S Movie(1,alias)="title"

S Movie(4,key)="sandbox.movie.imdbid"
S Movie(4,range)=STRING
S Movie(4,cardin)=ONE
S Movie(4,isa)=ATYPE
S Movie(4,unq)=UNQINSERT
S Movie(4,req)=1

D Assert^sapi(.Movie)
D Transact^sapi

Here, sandbox.movie.title is a required, single-valued string attribute with language-string validation.

sandbox.movie.imdbid is also required and single-valued, but additionally uses UNQINSERT uniqueness semantics. A duplicate IMDb ID is therefore rejected when inserted.

A corresponding attribute such as sandbox.movie.tmdbid can instead use UNQUPSERT. In that case, a duplicate TMDb ID does not produce a uniqueness error. Instead, the incoming record is resolved to the existing entity that owns that value and the new assertions are applied to that entity.

This illustrates the separation between an attribute’s descriptive metadata and its structural semantics. The key and namespace identify what the attribute is, while its range, cardinality, uniqueness, validation, and related metadata determine how the attribute behaves.

Naming Convention

Local attribute names, meaning the final segment of an attribute key, generally follow a controlled naming convention inspired by UN/CEFACT Core Component Data Types.

A local name represents a compound camelCase business term within a namespaced context. For example:

people.person.birthDate
people.person.alumniOf
people.person.additionalName

The namespace provides the context:

people.person

while the local name identifies the particular property:

birthDate
alumniOf
additionalName

This separates the business context from the property name and avoids requiring every attribute to have a globally unique, context-free name.

Namespaces

TaxisBase keys use a dot-notated namespace hierarchy.

The sys namespace is reserved for the TaxisBase system ontology and bootstrap definitions. It is distinct from user and domain namespaces such as sandbox or people.

For example:

sys.type.type
sys.type.attr
sys.val.string
sys.attr.range

belong to the reserved system namespace, while:

sandbox.movie.title
people.person.birthDate

belong to application or domain namespaces.

This distinction allows the system vocabulary and user-defined domain vocabulary to coexist in the same global keyspace while remaining logically separated by namespace.

Schema API Namespace Staging

The Schema API supports namespace staging through the ns parameter.

The namespace is supplied once for an Assert^sapi call and is combined with each record’s relative local key to produce the fully qualified key.

For example, given:

S ns="sandbox"
S Movie(1,key)="movie.title"

the resulting fully qualified key is:

sandbox.movie.title

This allows a schema definition to use relative keys while the API supplies the namespace context for the entire assertion operation.

The Role of Keys and Namespaces

sys.attr.key (EID 210) assigns every entity in TaxisBase a unique, dot-notated identifier.

Because every entity carries a sys.attr.key assertion, including value types, enumerations, composite value types, attributes, association types, and objects, the reverse value dictionary for sys.attr.key acts as the master registry of keys across the entire TaxisBase keyspace.

Conceptually:

^TBDR(210,key) → valkey

For example:

^TBDR(210,"sys.attr.abbr")="K0D2.01873F"
^TBDR(210,"sys.attr.alias")="K0D2.01878D"
^TBDR(210,"sys.cvt.geo")="K0D2.01880C"
^TBDR(210,"sys.cvt.geo.longitude")="K0D2.01882A"
^TBDR(210,"sys.enum.cardinality.one")="K0D2.0187E4"
^TBDR(210,"sys.type.obj")="K0D2.018820"
^TBDR(210,"sys.val.boolean")="K0D2.0186C1"
^TBDR(210,"people.person")="K0D2.018846"
^TBDR(210,"people.person.additionalName")="K0D2.018851"
^TBDR(210,"people.person.alumniOf")="K0D2.018857"
^TBDR(210,"people.person.birthDate")="K0D2.01885A"

Here, 210 is the EID of sys.attr.key. Therefore:

^TBDR(210,key)

is the reverse value dictionary for the key attribute itself.

Every literal key, regardless of its namespace, is registered in this dictionary. This includes keys from:

sys.attr.*
sys.cvt.*
sys.enum.*
sys.type.*
sys.val.*
people.person.*
sandbox.*

Each key resolves to its own value key, allocated from the monotonic value-key sequence for attribute 210.

Global Key Resolution

This design gives TaxisBase a single resolution path for human-readable keys.

Conceptually:

Human-readable key
        │
        ▼
^TBDR(sys.attr.key, key)
        │
        ▼
     valkey
        │
        ▼
      entity

Objects and Associations

In TaxisBase, an object represents the underlying identity of a topic, while associations provide independently modeled perspectives through which that topic can be described.

• An object (sys.type.obj) is a specific instance of a topic, such as a person, place, event, book, or movie.
• An association (sys.type.assoc) is a relationship-type entity that describes an object from a particular perspective. An association is linked to its object through an object attribute.

This separation allows a single real-world topic to be described through multiple independently schematized facets without forcing all of its properties into one flat record.

For example, Tom Hanks can be represented by a single object and described through separate associations such as:

obj.tom_hanks
    │
    ├── person
    ├── actor
    └── film producer

Each association can carry only the attributes relevant to its particular perspective, while all associations refer back to the same underlying object.

The object therefore provides stable identity, while associations provide contextual descriptions of that identity.

Example: Creating an Object

The following creates an object representing Tom Hanks:

S Obj(2,key)="obj.tom_hanks"
S Obj(2,doc)="American actor and filmmaker (born 1956) @en"
S Obj(2,name)="tom_hanks"
S Obj(2,isa)=OBJ
S Obj(2,alias)="TomHanks|%TomHanks"
S Obj(2,label)="Tom Hanks @en"
S Obj(2,wiki)="https://en.wikipedia.org/wiki/Tom_Hanks|
               https://fr.wikipedia.org/wiki/Tom_Hanks|
               https://el.wikipedia.org/wiki/Τομ_Χανκς"

D Assert^api(.Obj)
D Transact^api

The pipe character (|) delimits multiple values assigned to a multi-valued attribute in a single assignment. For example, sys.attr.alias and sys.attr.wikipage can accept multiple values.

During assertion, the assertion layer expands these into individual facts according to the cardinality defined for the target attribute.

Querying the resulting object with PE^api("obj.tom_hanks") resolves its stored facts back to human-readable attribute keys and values:

======
obj.tom_hanks
======
  65710bddc57dczsmgotm  sys.attr.key            obj.tom_hanks
  65710bddc57dczsmgotm  sys.attr.label          Tom Hanks @en
  65710bddc57dczsmgotm  sys.attr.name           tom_hanks
  65710bddc57dczsmgotm  sys.attr.alias          TomHanks
  65710bddc57dczsmgotm  sys.attr.alias          %TomHanks
  65710bddc57dczsmgotm  sys.attr.description    American actor and filmmaker (born 1956) @en
  65710bddc57dczsmgotm  sys.attr.wikipage       https://en.wikipedia.org/wiki/Tom_Hanks
  65710bddc57dczsmgotm  sys.attr.wikipage       https://fr.wikipedia.org/wiki/Tom_Hanks
  65710bddc57dczsmgotm  sys.attr.wikipage       https://el.wikipedia.org/wiki/Τομ_Χανκς
  65710bddc57dczsmgotm  sys.attr.isa            900

Entity ID schemes

TaxisBase separates schema-level entities from data-level entities through distinct ID schemes.

TBox Entities

TBox entities represent the schema and metamodel, including:

• Attributes
• Types
• Enumerations
• Composite value types
• Association types
• Other schema-level entities

They use small sequential integer IDs allocated from:

^TBEAVT("seq")

These IDs form the TBox identity space.

ABox Entities

ABox entities represent data-level instances, including objects and association instances.

They use KSUID-style string identifiers that are:

• Globally unique
• Sortable
• Suitable for distributed generation
• Disjoint from the TBox integer ID space

A new ABox ID is allocated when a new data-level object or association instance is created.

The distinction can therefore be summarized as:

TBox
 └── Schema and metamodel entities
     └── Small sequential integer EIDs

ABox
 └── Data-level entities
     ├── Objects
     └── Association instances
         └── KSUID-style string EIDs

This separation makes the distinction between the vocabulary used to define the database and the instances described by that vocabulary explicit in the identity layer itself.