NameShape

This page is generated from the code and must not be edited by hand.

Where the parts of one entry’s name sat, held apart from what they were.

Content and position do different work, so they are stored apart. What a file is about is conceptual and lives in Component. Which files form a series with it is relational and lives here. Putting an ordinal on a component would entangle the two and would force a second decision about whether that ordinal belongs in the component’s identity. Keeping them apart enforces the separation in storage rather than by discipline, and it makes the question of whether content and position should be weighed together or separately a rule-level experiment rather than a storage rewrite.

What this record exists to enable, stated because a record that cannot express it is the wrong record. Files in one folder sharing a skeleton and differing at exactly one slot are equivalent in the respect the skeleton supplies, and the differing slot names the relation: a bare number is a replicate series and succeeds, a date is a time series, a quantity whose dimension is a concentration is a dose series. One rule reading a shape and one differing slot emits those edges with a stated respect and learns nothing. The rule is not written; this is the record it will read.

Fields

Field	Type	Required	If left out
entry_id	text	yes
name_shape_id	text	yes
normalizer	text	yes
normalizer_version	text	yes
run_id	text	yes
schema_version	text	no	"1.23"
skeleton	text	yes
skeleton_hash	text	yes
slot_count	whole number (at least 0)	no	0
slots	list of NameSlot	no	[]
source_scope	SourceScope	no	"name"

The types named above are described on the shared types page: NameSlot, SourceScope.