Term, label, tag - Best Practices

[kbwissi]

As we start to roll out our connect instance, I'm wondering if anyone has any best practices on when to use a glossary term vs. tag vs. label vs. etc. Obviously, each setup will be unique but just looking for general guidelines to get started.

[VojtechT]

Hi @kbwissi ,

I cannot provide you with any "rule" or "best practise", but my rules of thumb would be:

1. Label vs. Tags - there is a "little" inconsistency in Connect regarding these. On the asset, you assign "Tag", but those Tag-values live under "Labels" page. Thus I think "tags" and "labels" are technically synonyms, even though semantically the word "Tag" is the correct one that should be used. 

2. Term vs. Tag - I would say it's not about using one or another, but actually both are correct depending on the use case. There can be both "Sales" Term as "Sales" Tag. The term is suppose to describe what the word actually means for you, so when others are using the term, they can be sure they are using it in the same meaning. On the other hand, the purpose of "tag" is to aggregate similar assets, so it's easier to find them and navigate among them. E.g.: You have 10 reports and each one of them is different, but all of them are more or less about Sales, so you give them the Sales tag. 

Plus - a Term is "definite" - there should be only one possible meaning of the Term. While it is perfectly ok of having multiple Tags per asset. 

So at the end - it makes perfect sense to have Sales term with Sales tag assigned to it. 

Is this the kind of information you were looking for or this has been pretty clear, but you are looking for more "hands-on" experience?

[DavidM]

@kbwissi I think it may be good to refer to the article 10 Tips to Build a Successful Data Catalog.

I would think that TAGGING is relatively unstructured and decentralised way to simply put a big picture label to  assets. I.e. this report has something to do with for instance SALES. Thus we tag it.

Once you are actually thinking about capturing the language of your business in a more structured manner (refer to that article above) then you want to start thinking business glossary.

I.e. centralize explanations of business terms like SALES QUOTA, SALES PIPELINE, PROPOSAL, CUSTOMER, PRODUCT etc. And link this across layers of reports, data sources, workflows.

Hope this helps.

[No-Sass]

So with this in mind, would it be said that good place to start with Connect would be to add definitions to the field/column names for loaded databases(or data-sources)? Then, for any of those fields that are a business term, add a link to the definition field that connects that field name to a glossary term?

Table = Sales

Column Name = AGENT_NO (Agent Number)

Definition = Unique identifier assigned to every agent <Glossary Link to Agent Number> <Glossary Link to Agent>

[DavidM]

@No-Sass one of the possible approaches, yes.

[James_First_Mile]

@No-Sass - your approach is spot on. Starting with the definitions of your data elements will help you quickly identify gaps in your business glossary. Using your example, as you write the definition for your data element, you can maintain a list of missing words/terms to add to your glossary at a later time.

When starting out, I like to take this approach:

• Identify your critical data elements (CDE) - the data that is critical to the success of your business. Not only will that keep your scope manageable, it will ensure that your efforts were spent on the data assets that the majority of your organization care about

• In Connect, after your Datasources are loaded, go to each CDE and tag it accordingly

• Now you have a running list of your CDE's that you can find anytime just by typing CDE in the search bar

• That list is your finite scope to start annotating each element (i.e. adding alternate name, description, relationships, other tags) to build a 'context ecosystem' around your CDEs