Hi Madhan,
I have a look in the code - I was surprised that the tag propagation was
not in. Is this something you are looking at in the near future? If not I
may need to look into it. I suggest the tag propagation implementation
should phase 1 should:
- lose BOTH - this is still in the code - I think we agreed we wanted to
get rid of this.
- should honour the classification entitytypes - so that we do not get
classifications applied to inappropriate entityTypes
- There is the question about how the propagated classifications would
look in the get entity rest API  - I suggest that they appear in the
entities classification with a field indicating that they are derived (and
hence not able to be removed by an entity update).
- I would hope that Ranger would pick up these new propagated tags using
the existing tag sync.
- I think you wanted the derived classifications to be picked up at query
time. I also remember suggesting that we store the derived classifications
in a derivedClassifiation property in the entity which would contain the
list of derived classifications. Or we could store them as a new type of
edge "propagated classification" edges to the real classification. I like
the edge idea.

If we had the above, we could classify a Term as PSI, and use the semantic
mapping to propagate the classifications to the hive column. The hive
column would not pick up classifications defined in the area 3 model like
"SpineObject", which is defined as only applying to "GlossaryTerm".  

What do you think?   all the best, 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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB