2026-07-30 20:58:26 +02:00
|
|
|
# Demand: Attribute Value Type Catalog
|
|
|
|
|
|
2026-08-15 19:42:30 +02:00
|
|
|
**Status:** accepted (canon 0.6.0)
|
2026-07-30 20:58:26 +02:00
|
|
|
**Date:** 2026-07-30
|
|
|
|
|
**Source:** citation-evidence Capture UX (consumer)
|
|
|
|
|
**Related consumer draft:** `citation-evidence/wiki/AttributeValueTypes-proposal.md`
|
2026-08-15 19:42:30 +02:00
|
|
|
**Workplan:** ITC-WP-0013
|
|
|
|
|
**Catalog:** `infospace/models/data/attribute-value-types.yaml`
|
|
|
|
|
**Alignment:** `infospace/models/data/attribute-value-types-alignment.md`
|
2026-07-30 20:58:26 +02:00
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## Demand signal
|
|
|
|
|
|
|
|
|
|
Consumer **citation-evidence** needs a **closed, versioned catalog of
|
|
|
|
|
attribute value types** for evidence-backed structured capture (key / type /
|
|
|
|
|
value), including:
|
|
|
|
|
|
|
|
|
|
- `time`, `datetime`
|
|
|
|
|
- `amount` (quantity + currency)
|
|
|
|
|
- `one-of` (single selection from a code list)
|
|
|
|
|
- `some-of` (multi selection from a code list)
|
|
|
|
|
|
|
|
|
|
plus existing scalars `text`, long text, `date`.
|
|
|
|
|
|
|
|
|
|
The consumer must not invent a permanent private type system if InfoTechCanon
|
|
|
|
|
is the semantic reference layer for info-tech domains.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## Gap vs current canon
|
|
|
|
|
|
|
|
|
|
`InfoTechCanonDataModel` already defines:
|
|
|
|
|
|
|
|
|
|
- Attribute, Field, DataElement, Representation, DataType, CodeList, Constraint
|
|
|
|
|
|
|
|
|
|
But:
|
|
|
|
|
|
|
|
|
|
- **DataType** is only a one-line stub,
|
|
|
|
|
- **Representation** lists open examples without a closed catalog,
|
|
|
|
|
- there is **no** machine-readable AttributeValueType registry for application
|
|
|
|
|
forms / capture UIs.
|
|
|
|
|
|
|
|
|
|
This demand is for a **canonical collection of value types** (and encoding
|
|
|
|
|
rules), not for a new domain entity competing with Attribute/Field.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## Proposed placement
|
|
|
|
|
|
|
|
|
|
**Preferred:** extension or section under **ITC-DATA** (Data Model):
|
|
|
|
|
|
|
|
|
|
- concept: `AttributeValueType` (or closed `Representation` profile for
|
|
|
|
|
capture/forms)
|
|
|
|
|
- artifact: markdown standard + YAML catalog under `infospace/`
|
|
|
|
|
- relationships: AttributeValueType → CodeList (for one-of/some-of), → Constraint
|
|
|
|
|
|
|
|
|
|
**Avoid:** scattering type ids only inside citation-evidence.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## Success criteria
|
|
|
|
|
|
|
|
|
|
1. Closed list of type ids with definitions and wire encodings.
|
|
|
|
|
2. Clear mapping to Representation / CodeList / Constraint.
|
|
|
|
|
3. Consumer citation-evidence can depend on the catalog (copy or generated
|
|
|
|
|
constants) without forking names.
|
|
|
|
|
4. Processed via Purpose/Demand if required by ITC-WP-0006 before kernel edit.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
## Non-goals
|
|
|
|
|
|
|
|
|
|
- Full statistical data type system.
|
|
|
|
|
- UI widget standards (consumer concern).
|
|
|
|
|
- Vendor form-builder schemas (SurveyJS, etc.) as canon.
|
