Support field datatype rather than is_time

[khush-bhatia]

Discussed in #25

^{Originally posted by jonmmease January 16, 2026}
I'd suggest that a logical datatype field be used in place of the proposed is_time field. For consumers of semantic models, the data type can be important when building logic on top of dimensions. A motivating example is a BI tool that supports its own expression language on top of dimensions to compute local derived fields or local measures for visualization. Having correct type information can be critical for working with dimensions properly.

I would suggest enumeration values of:

• number
• string
• boolean
• time
• timestamp
• timestamptz
• opaque/other (for anything else)

For reference: LookML, Cube, and Hex require this information in their specs

[khush-bhatia]

Another related discussion #17

[jonmmease]

Thanks @khush-bhatia, what's the process from here toward getting the spec updated?

[khush-bhatia]

Hey @jbonofre What be your suggestion for cases like this ? I think this change is not big enough that it needs to be discussed in a working group. But it will end up being a breaking change to the spec.

I have also confirmed that most BI tools do have the datatype in the spec but not sure if there is alignment on the spec for datatypes between all the BI tools.

Instead of adding a datatype spec to OSI, should we leverage any other existing spec for datatypes(like ANSI SQL ) ?

[KSDaemon]

Yes, this is a great idea — I’d like to support it.

We’re already using something similar on our side: we introduced this data_type in the dimension object. It would be great to have it as part of the official specification rather than as a separate workaround.

If needed, I’d be happy to prepare a PR with the proposed update.

[jbonofre]

I'm fine to move forward with a PR. If a TSC member approves, we are good to go 😄

[khush-bhatia]

@jonmmease Let me know if you would to take this issue and create the PR ?

[jonmmease]

yes, I'd be happy to create or review a PR

[xavipereztr]

Hi @khush-bhatia!

Two thoughts on the proposed enum before it moves forward:

On number being warehouse-dependent
The number type may carry different semantics depending on the data warehouse, which could undermine the interoperability the spec is trying to provide. A few concrete examples:

• BigQuery doesn't recognise NUMBER as a keyword — its fixed-point type is NUMERIC, defaulting to (29, 9): up to 9 fractional digits preserved.
• Snowflake accepts NUMBER but defaults to (38, 0), behaving like an integer — fractional digits are silently truncated on write.
• Databricks accepts NUMBER with a default of (10, 0) — also integer-like, with a smaller precision ceiling.

So a value like 1.5 in a column declared as unqualified NUMBER/NUMERIC survives on BigQuery but is silently truncated to 2 on Snowflake and Databricks. Precision ceilings also diverge (29 vs 38 total digits).
It might be worth either (a) splitting number into integer, float, and decimal to be unambiguous, or (b) keeping number as a broad category but documenting explicitly that consumers should treat it as a hint, not a contract. Either way, worth flagging before the enum is locked in.

Spatial Dimension
We'd strongly support adding geometry and geography as first-class values in the datatype enum. Right now, a WKB polygon column and an H3 spatial index string are both string or opaque in OSI; consuming tools have no way to distinguish them from free-text fields.

geometry and geography mirror the OGC/ISO SQL distinction and the naming used natively in BigQuery, Snowflake, PostGIS, and the majority of platforms, so they'd be well-understood values with no ambiguity across data platforms. We're separately preparing a proposal to extend the dimension concept with a richer is_spatial descriptor (geometry type, SRID, spatial index system, geographic hierarchy), but the datatype enum is the right first hook, even a bare geometry or geography value gives consuming tools the signal they need to handle spatial columns correctly.

Happy to contribute this as part of the PR if it's in scope.

[jonmmease]

Hi @xavipereztr, I happened to be working on a PR for this while you were writing the comment over at #113.

Happy for feedback and to iterate on the types there