As a service builder, I need entities to be identifiable in plain language so that services can present information clearly, support user journeys, and avoid confusion caused by technical references alone.
- Priority
- medium
- Status
- proposed
- Themes
- data-principle
- Actors
- service-builder
- Source
- data-design
Justification
Justification just-0017
The current rule requires a `name` field on every dataset, giving services a consistent display label. This matters when planning decisions rely on human judgement and discussion rather than long identifiers. The rule is too broad at present. Datasets representing a user-recognisable entity or document should provide a human-readable name. Relationship and event datasets should normally derive their display label from referenced records or controlled values, rather than storing a duplicate `name` field. For example, a planning condition name lets services present conditions clearly instead of relying on codes alone, and a site name lets planners refer to the site in discussions and reports with less ambiguity. Conversely, a decision-condition record should normally display the name of its referenced planning condition, and a timeline record should display the controlled process event and its date. The rule should be refined to express this distinction between a stored name and a derived display label. Until then, it records a useful design intention, but should not be read as requiring an artificial `name` field on every dataset.
Satisfaction: full; Confidence: high
Satisfied by:
Rule:
{
"applies_to": "dataset",
"requires": [
{
"field": "name"
}
]
}
See complete justification record: just-0017