Replace is_time with dimension_type Enum

[dmzolotarev]

The current dimension.is_time boolean is not scalable, it doesn't allow us to add other types of possible dimensions that we might add:

• Geographic dimensions (country, region, coordinates)
• Categorical dimensions
• Ordinal dimensions

Proposed Solution:
Replace the dimension object with a dimension_type enum that's more expressive and scalable.

[cpimhoff]

Related: #25

[fas89]

Adding a data point from data-product-forge: our modeler emits a time grain (day/week/month/quarter/year/hour/minute) on every time dimension because both of our downstream targets need it — dbt MetricFlow requires time_granularity on time dimensions, and our own query layer uses it for date-trunc. Since the Dimension object only carries is_time, we currently tuck the grain into a vendor custom_extension at emit time.

So if this lands as a richer dimension_type, having a granularity slot on the time variant would let converters round-trip MetricFlow and Snowflake semantic-view models without vendor extensions. We also keep an alias table for normalizing user input (daily, hr, mins, and so on) — happy to share it if useful.

[hikarilabs]

@fas89 see bellow .. I added to the thread by mistake instead of a direct response

[hikarilabs]

Adding a second data point from semantido (Python/SQLAlchemy semantic layer with an OSI exporter): we hit the same wall independently. Our model carries a TimeGrain enum per temporal column (second/minute/hour/day/week/month/quarter/year), and because Dimension today only exposes is_time, we serialize the grain into a vendor custom_extensions block at export time, structurally the same workaround the data-product-forge describes. Two implementations independently inventing the same vendor extension for the same field seems like decent evidence the slot belongs in the spec.

So +1 to a granularity slot on the time variant of a richer dimension_type. Two design notes from our implementation experience:

Grain vocabulary as a closed enum, aliases in tooling. We'd argue for a fixed enumeration in the spec (day, month, etc.) with normalization of user input (daily, hr, mins) treated as an authoring-tool concern, not a spec concern. Converters round-trip cleanly only if the wire format is canonical. The alias table data-product-forge offers would be a great shared tooling resource without needing to live in the spec.
A conformance note on physical compatibility. In semantido we validate at sync time that a declared grain isn't finer than the underlying column type can represent (e.g. minute grain on a DATE column fails fast rather than exporting a claim the warehouse can't honor). The spec probably shouldn't mandate validation, but a non-normative note that producers SHOULD ensure grain/type compatibility would help converter authors decide what to do with inconsistent inputs.

One adjacent issue we'd flag as separate scope: grain answers "how fine is this column," but not "which of a table's several temporal columns is the intended analysis axis." Fact tables routinely carry created_at / updated_at / trade_date / settlement_date, and in our text-to-SQL testing, picking the wrong axis was a larger error source than wrong truncation. We model a primary-time-axis designation per dataset for this reason (currently also exiled to a vendor extension). Happy to open a separate discussion on that if there's interest, mentioning it here only because a richer time dimension type is the natural place such a flag would eventually attach.