Ontology architecture in Workshop

Ask the Community
,
1

Hi everyone,

We are currently working on designing an ontology architecture in Workshop and would like to get some input and recommendations from the community.

Right now, we are debating whether it is better to:

  1. use one large denormalized (flattened) object, or
  2. keep multiple normalized linked objects that reflect the real relationships in the ontology.
    Key questions

Performance: normalized vs denormalized
From our experience, working with many small objects with multiple links and transversals seems to noticeably worsen Workshop performance, especially in dashboards and derived properties.

Because of this, we are leaning towards using a single large denormalized object instead of multiple linked ontology objects. Is this a common experience, and is it generally recommended to move towards a more flattened object structure in Workshop to improve performance?

If so, what is the practical benefit of maintaining a fully normalized ontology with many linked objects and transversals?

Derived properties across indirect links
We are currently facing a limitation where derived properties only work on directly linked objects.

Example:

Budget → Customer → Orders

When starting from the Budget object, we cannot add Actual Revenues from Orders as a derived property because the relationship is indirect.

How should this be handled in a best-practice ontology design?

Essentially, we want to understand:

Is it better in Workshop to work with one large object for performance, or split objects and maintain a clean ontology, and how to balance both?

We would really appreciate insights from teams that have already built larger ontologies in Workshop and faced similar trade-offs.

Thanks in advance!

1 Like
2

I like to tell people you should be “half normal” with your ontology for a database.

However, please keep in mind the core philosophy of an ontology: it represents your business. I see a lot of technical folks forget that. So do what will make sense for your business and don’t worry quite as much about getting it normal vs not normal.

With that out of the way:

I’ve found that with derived properties, some of the issues go away with requiring giant wide tables. This is specific to widgets like pivot tables especially, who seem to require the property in the object itself.

Experiment first with what you want to display and how and work backwards on your ontology.

You can also use functions to do some “internal jumps” if required for displaying data in your revenue example.

How comfortable is your team with coding? If you can leverage python/typescript, I wouldn’t worry too much. Are you coming from more of a powerbi style of working? DAX?

https://palantir.com/docs/foundry/functions/create-custom-aggregation/

Above is an example for your revenue question.

1 Like