Interface: CreateTermByNameRequest
@kortexya/reasoninglayer / CreateTermByNameRequest
Interface: CreateTermByNameRequest
Section titled “Interface: CreateTermByNameRequest”Defined in: src/types/terms.ts:242
A term write that names its sort by NAME rather than by id.
Remarks
Section titled “Remarks”POST /api/v1/inference/facts and every OSFQL write have always taken a
sort name; the term routes took only a UUID, so a caller holding names had
to resolve every sort first — worst on the bulk route, the one place the
extra round trips cost most, because it exists for volume.
Exactly one of the two spellings per entry. Both deny unknown fields on the
wire, so an entry carrying sort_id AND sort_name matches neither and is
refused — measured, 422 data did not match any variant of untagged enum CreateTermInput. A name this tenant does not declare is refused too, and it
never mints a sort: 422 unknown sort \nosuch`: this tenant declares no
sort by that name. Declare it first, or name the sort by `sort_id`.`
Serialization format: features use the tagged ValueDto format, like every term-CRUD route.
Properties
Section titled “Properties”features
Section titled “features”features:
Record<string,ValueDto>
Defined in: src/types/terms.ts:258
Named features with tagged values.
Remarks
Section titled “Remarks”A feature whose declared range is an entity sort takes a Reference
(Value.reference(termId), {"type": "Reference", "value": "<uuid>"}),
not a string holding the id: the engine refuses a scalar literal there
with 422 (Feature '<f>' holds a <kind> literal, which is incompatible with the declared range …). A range at or below real_type admits an
integer literal.
optionalid?:string
Defined in: src/types/terms.ts:260
A client-minted id, read exactly as CreateTermRequest.id.
ownerId
Section titled “ownerId”ownerId:
string
Defined in: src/types/terms.ts:246
Owner user ID (UUID).
sortName
Section titled “sortName”sortName:
string
Defined in: src/types/terms.ts:244
The sort’s name, resolved against the tenant’s lattice.