Field note

Can JSON Schema start a data dictionary?

A flat object schema can supply field names, titles, descriptions, required flags, types, and enumerations. It may be a strong starting point, but technical constraints rarely provide the whole reader context.

Supported descriptive subset

A flat object schema is read for its property names, and for each property the title becomes a label, the description becomes a starting definition, the required list sets the required flag, the type becomes a declared type, and an enumeration becomes a starting set of allowed values. Nested objects and arrays of objects are not expanded into fields. The studio reads a schema as documentation, never as a validator.

Preserve the authored schema

Type names are translated explicitly rather than passed through: a schema string becomes text, a date format refines it to a date, a union with null documents the non-null type, and two real types document as mixed. Anything unrecognised lands as unknown so that it surfaces in the review instead of looking settled. Your schema file is not modified and is not stored in the project.

Review before validation use

A schema says what a document is permitted to contain. It does not say what one record represents, how the values were collected, at what measuring basis, which absences mean what, or who owns the definition, and those are the parts a reader actually needs. Read every translated type and definition before accepting it, then add the context the schema cannot carry.

Worked example from the sample project

A flat object schema supplies more than a delimited file does. Field names come from the properties, and a title becomes a readable label, a description becomes a starting definition, a required list becomes the required flag, and an enum becomes a starting value set. That is a genuinely useful head start on a folio.

The translation is not a pass-through, and one detail is worth knowing. JSON Schema spells its primitives differently from the studio's documentation types: a schema string becomes text, a format of date refines it to a date, a nullable union documents the non-null type, and two real types document as mixed. A word that is not translated would land as unknown, which is why the mapping is explicit rather than implicit.

What a schema still does not carry is the reader context: the universe, the collection method, the measurement basis, the owner and the reason a constraint exists. A schema tells you what is permitted. A dictionary tells you what it means.

What this does not do

Only a flat object schema is supported; nested structures are not documented as fields.
Importing a schema does not validate any data against it.
A constraint is not a definition, and an enum is not a set of meanings.

Do this in the studio

Take the names, titles, descriptions and enums, then write the context the schema cannot hold.

Open the Import structure station and load the schema.
Review each translated type before accepting it.
Add the universe, method, unit and owner that the schema does not carry.

Open the studio at the Import structure station