atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shwetha Shivalingamurthy <>
Subject Re: Improvement suggestion: change terms to be implemented as entities
Date Tue, 13 Dec 2016 04:43:40 GMT
Modeling terms as traits also enabled search work out of the box. For
example, queries like search for assets with term will map to ŒAsset isa
<term>¹ (though this worked only for leaf terms)

Modeling terms as entities will simplify some of the functionalities like
term renames, move term from one hierarchy to the other etc. Are you
planning to expose different way of searching or use existing search like
ŒAsset where terms = <term>¹?


On 13/12/16, 7:50 AM, "Hemanth Yamijala" <> wrote:

>I hope folks who are more plugged into Atlas on a day-to-day basis will
>provide relevant feedback. I have a very few comments below.
>Regarding point 10: AFAIK, the most significant constraint of
>implementing terms as entities was that entity to entity relationships
>needed to be predefined, while tags / traits could be associated to any
>entity without this prior definition.
>Regarding point 7: Tags and traits are indeed interchangeable. In the
>Atlas UI specifically, we always refer to trait types as tags (which is
>confusing IMO, but well, that's where we are)
>From: David Radley <>
>Sent: Monday, December 12, 2016 11:27 PM
>Subject: Improvement suggestion: change terms to be implemented as
>I have raised Atlas Jiras 1254 an 1245. I would like your feedback on
>changing the implementation of business/glossary terms to be entities,
>rather than trait types and trait instances. This would mean:
>1) A Term would have a guid for ATLAS-1245
>2) TermResourceDefinition could be changed to add relationship
>projections, to support ATLAS-1254. I suggest we have "has a" , homonymns
>and antonyms as the relationships.
>        - has-a relationships would allow us to associate a Hive table
>with one term and its columns with other column related terms. So we could
>then work with the  the business glossary terms and it would be aware of
>the conceptual has-a relationship; rather than needing to interrogate the
>asset. Of course glossary terms could be associated using has-a
>relationships without being mapped to entities.
>        - homonyms and antonyms are commonly used with business glossaries
>3) We would not have a new trait type that would be created for every term
>- that cannot be deleted. Instead we would have 1 system type for term
>that all terms entities would be associated with.
>4) We would need to ensure we could still support for available_as_tag for
>terms - this means we expose the term by name as a tag
>5) I suggest we tolerate gets on the term using the the guid in the URI as
>well as the fully qualified name. Creation of new terms should create
>hrefs with the guid.
>6) Term to term relationships would be simple in the code as we would use
>an entity to entity relationship.
>7) I notice in the the Atlas technical user guide (page 60), talks of
>traits and tags terminology as being interchangable. In the code (apart
>from in the supplied trait types),  it seems that traits are only used to
>implement terms, I guess because terms are often known by their name. Tags
>are somewhat different as they are used to interact with Ranger for tag
>based policies.
>8) The Atlas technical user guide talks of 2 ways of categorizing entities
>, the business taxonomy and tags / traits. This change would be in line
>with the separation.
>9) Having a guid for terms would allow us to rename the term without
>changing its identifier. I assume we should allow multiple terms of the
>same name in different taxonomies.
>10) I think the reason that terms were implemented as trait instances as
>traits are identified by name so do not need guids and if a trait was an
>entity, a user could define a relationship to a term entity, which would
>be confusing. My suggestion is that if the user chooses to create a type
>with a relationship to a term, then we reject the creation of the type .
>At the moment they presumably could create a relationship to a taxonomy
>which we should also reject.
>11) As part of these changes, I suggest that entities also contain a
>response field of terms. So it is more obvious to a REST client what the
>associated terms are with an entity.
>Please let me know if I have missed/misunderstood/misrepresented anything.
>I appreciate your feedback, as I hope to address these Jiras soon,
>many thanks , David.
>Unless stated otherwise above:
>IBM United Kingdom Limited - Registered in England and Wales with number
>Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

View raw message