How to deal with AKAs without creating multiple assets?

I’m hoping someone can provide a solution to a challenge I’ve been facing. We’re using Collibra to support a medical group and working to build out our glossary and relationships, and we’re finding synonyms in various areas of our organization.

As an example, in one report we have ‘indwelling urinary catheter’ listed which is referred to in other reports as a ‘foley catheter’ which is a different name for the same thing. I know the relationship ‘is synonym’ is available but it seems like a waste of time and data to enter a completely separate business asset to then build the relationship. Is there a better way to add an AKA to a glossary term ? Assuming Collibra allows it I’m thinking we need to create a new ‘characteristic’ of AKA, thoughts?

Thanks in advance,

Jered

Former User

Posted 5 years ago · Edited 1 year ago·Last reply 5 years ago

5 comments

stephenmc_donald

·5 years ago · Edited

Interesting discussion points here - I can see the use of acronyms and synonyms been beneficial in establishing glossary at an Enterprise level which would remove the creation of multiple Business Terms for the same item.

One thing to probe is in examples where the Business Term is used in multiple business areas, let’s use the example Currency, if we have one reference to this BT in the enterprise glossary which is used in multiple business areas such as Finance, Procurement and Trading how do we reflect the different consumers and golden source of this data in these areas best?
In essence we could have three different combinations of the same BT sourced from different Golden source and servicing different consumers.

At the moment we have three discrete BT with each mapping to the goldens source and consumers as required in different communities.
Would adding a Business Process or Entity level to the data which could be filtered upon be the best approach in terms of having the multiple versions of lineage available. This would allow a singular reference to the Business Terms and the flexibility to build different versions of lineage across the organisation.

I would be interested in hearing thoughts/examples on how this can be done at an Enterprise level.

Former User

OP5 years ago · Edited

Jered, @arthur.burkhardt and @ronald.schaareman have provided good options for you. I would step back and make sure you keep focus on what you’re hoping to achieve with your glossary in the long run. If it’s to get everyone speaking the same language you need to think about how you’re going to accomplish that given whatever approach you choose. For us, it’s most effective to create synonyms and acronyms with relationships to the business term. The synonyms and acronyms get boilerplate descriptions essentially pointing the reader back to the related (preferred) term(s). For us, this makes it easier to highlight cases where acronyms and synonyms are used (often by different groups) to refer to different business terms. In these cases, the danger is they think they’re talking about the same thing, but they’re not.

Using our approach, it is easy for people to search for things by the name they know. When they see the synonym (for example) they understand that it’s not the preferred name, they can see that other people may use it differently via the links to different terms. They can then go straight to the related business term that’s the best match for their context to see the definition. This also helps the central DG team identify cases where people may be getting confused by the names in play. This is also very important for acronyms / abbreviations - people seach for an acronym (e.g. POS) and it’s much easier to see all the different things it can can stand for via relationships - there is no one definition for POS - it could be valid for Parents Over Shoulder and Point of Sale - context will guide people to the right, related business term.

Former User

OP5 years ago · Edited

Thank you @arthur.burkhardt and @ronald.schaareman. Both of you gave good info and some more food for thought and some directions to investigate and consider. Much appreciated!

Ronald Schaareman

·5 years ago · Edited

Hi @jered.greenwald,

Although the question is to do AKA’s without creating multiple assets, we have switched to using a relationship instead and by that multiple assets. But it depends on your goal. I operate in Finance, which is of course a completely different ballgame than healthcare, but the considerations to switch to multiple assets are a.o:

there were multiple aliases around (so you get multiple attributes for an asset which did not show nicely);
there were different owners for the various aliases;
you can add more details on an asset type (so not only owner, but also definition - are they indeed the same? - and e.g. for which report is this asset applicable) and
an attribute does not show well in a diagram (you can only add it as an overlay).

Hope this helps.

Kind regards,
Ronald

arthurburkhardt

·5 years ago · Edited

Yes, we have created an “alias” attribute. The advantage compared to a “is synonym” relationship is that you can list multiple aliases even if they are not instantiated as business terms and it retrieves the right assets in the search, which a relationship cannot do.
You should look into standardizing the business glossaries with an “enterprise glossary” or uber glossary, that would deduplicate the terms, then you can link them to a data category so that the same term appears in both domains.

You can find some inspiration in the Covid-19 catalog: https://covid-19.collibra.com/vocabulary/cc96d970-d3f5-44e6-ab31-3fd76f4970b4
They maintain business terms in separate domains, but display them in a single domain. You could do the opposite here, maintaining them in a single domain but displaying them in multiple domains.