Tag propagation

[David Radley <da...@uk.ibm.com>]

Hi Madhan and Sarath,
We had a good discussion yesterday around tag propagation. To summarize:

1- Madhan was keen that we do not allow the removal of entityTypes from 
ClassificationDefs, if there are any instances of that classification 
applied to that entityType or any of its subtypes. I will amend the fix I 
submitted to account for this.
2- We will allow ClassificationDef updates of entityTypes to empty lists  
3- We talked of removing the relationshipDef tag propagation BOTH option - 
as this is complicated and difficult to implement. It is also not obvious 
what the use case is.
4- We talked of tag propagation not taking into account the Classification 
entityType restrictions 
5- We talked of tag propagation stage 1 at the relationshipDef level, 
stage 2 being a way to scope to entityTypes, stage 3 being able to 
override at a relationship instance level. The thought was that we store 
the state we need in entity to entity edge properties. 
6- David thought there were cases where we might want some tags to flow 
one way and different tags to flow the other way. for example the tag 
propagation we want for retention classifications is likely to be 
different from personal sensitive information classifications 

I have been thinking about 4, I think we need a compelling reason to not 
honor the model. If we have 
ClassificationDef A defined with entitytypes ["EntityA"] 
ClassificationDef B defined with entitytypes ["EntityB"] 

Then we should not be able to propagate tag A from EntityA to EntityB, as 
a get EntityB should never show classification A against it. Is there a 
use case for this? 

I think that if ClassificationDef A needs to be applied to "EntityB" then 
the user needs to change their models to add entityB to the entityTypes or 
the entityTypes restrictions be removed. If we do this we have a way of 
scoping the way tags propagate, so inappropriate (model violations) tags 
do not end up on entities. 

One way to implement this would be for the classificationDef and 
classification vertices in the graph (traits) to store the effective 
entityType names they can be applied to. We already resolve the effective 
types at addtype time in resolvereferences. This would be an easy check 
for Saraths's propagated tag impact/ed gremlin queries to take account of. 
 This seems to go some way to meet the stage 2 we were thinking about. The 
nice thing about this approach is hat we could replace the relationshipDef 
tag propagation enumeration with a rule that ran at addtype side (without 
needing to run the rule at query time). 

Let me know if I misrepresented or omitted anything.  I am really 
interested in your feedback and thoughts,
   all the best, 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