Mailing-List: contact dev-help@atlas.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@atlas.incubator.apache.org
In-Reply-To: <1481595640719.37413@hortonworks.com>
References: <OF212DE043.DF9B6A72-ON00258087.005758E9-80258087.0062A3A6@notes.na.collabserv.com> <1481595640719.37413@hortonworks.com>
To: Hemanth Yamijala <hyamijala@hortonworks.com>
Cc: dev@atlas.incubator.apache.org
MIME-Version: 1.0
Subject: Re: Improvement suggestion: change terms to be implemented as entities
From: David Radley <david_radley@uk.ibm.com>
Date: Tue, 13 Dec 2016 10:47:26 +0000
Content-Type: multipart/alternative; boundary="=_alternative 003B45EF80258088_="
Message-Id: <OF880E481E.7C09C5FB-ON00258088.003AB037-80258088.003B4656@notes.na.collabserv.com>
archived-at: Tue, 13 Dec 2016 10:47:46 -0000

--=_alternative 003B45EF80258088_=
Content-Type: text/plain; charset="US-ASCII"

Hi Hemanth,
On point 10 - I suggest that all assets would have a "system" optional 
predefined multiplicity relationship to terms (which in this proposal will 
only be one type, so could be a standard entity to entity relationship). 
Does this work for you? 

I suggest on the tag / trait front - we move to clarify the language in 
the docs and APIs around these entities so there is no ambiguity, 

many thanks , David. 


From:   Hemanth Yamijala <hyamijala@hortonworks.com>
To:     "dev@atlas.incubator.apache.org" <dev@atlas.incubator.apache.org>
Date:   13/12/2016 02:21
Subject:        Re: Improvement suggestion: change terms to be implemented 
as entities


David,

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)

Thanks
hemanth
________________________________________
From: David Radley <david_radley@uk.ibm.com>
Sent: Monday, December 12, 2016 11:27 PM
To: dev@atlas.incubator.apache.org
Subject: Improvement suggestion: change terms to be implemented as 
entities

Hi,
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
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--=_alternative 003B45EF80258088_=--