Regarding ontology/naming of 'dimensions'

I wanted to propose an alternative naming for what currently are called ‘dimensions’ - instead calling them ‘facts’, ‘attributes’, or ‘properties’.

So, on the docs page here, we’d go from

The dimensions you see in Lightdash are the columns that you’ve defined in your model’s dbt YAML file. If you include descriptions for your columns, these will be pulled into Lightdash automatically!

to:

The attributes you see in Lightdash are the columns that you’ve defined in your model’s dbt YAML file. If you include descriptions for your columns, these will be pulled into Lightdash automatically!

This gives Lightdash the ability to make ‘dimensions’ a higher-order element with intelligence such as ‘dimension_type’: time, enum, hierarchy, discretized, etc.

This also keeps us out of a sticky situation where a column like sales_revenue is a categorized as a dimension by default. Certainly, after bucketizing, sales_revenue could be used as a sales_revenue_tier dimension, but that requires applying a certain treatment, similar to how a certain treatment or calc may be needed to applied to metrics.

Another benefit is that day-month-quarter - year can roll up to a hierarchical dimension named time period or similar without themselves being ‘dimensions’ on their own.

[TuringLovesDeathMetal]

I’ve just run into this again.

I really like the word properties here - I feel like this is how I would talk about the columns in a table to a random person who’s never used Looker before.

[TuringLovesDeathMetal]

I think we’re sticking with dimensions so closing this issue!