Hi, Great points Nigel! I am looking to have a small checkin that does not impede the sort of enhancements you are talking of.
Responding in order: My thought was that we would use classification categories. Maybe one way to introduce ordering would be to have a 'has ordered children' flag on the category or a Ordered List container; then the children classifications would be expected to have a pointer to the next higher classification. If sub classification is important, it might be implemented using child categories, applying more than one simple classification or introducing inheritance classification. My suggestion would be to deal with this in a follow on Jira to address a particular use case.. I see terms as top level elements in the current code because: - there is a top level ResourceDefinition for Term at the same level as entity , taxonomy , tag etc. - the taxonomy API that returns terms as top level object. Internally terms do create a trait type and a trait instance. The traits are exposed in the API when an entity has a trait, which is what it knows the term as (maybe we could think of this in uml terms as an entity class, which has an attribute called trait of type term). It seems to me that we could view a term as a semantic classification; so we could rename traits to classifications in the entity API. We do need to be able to apply governance classifications to terms; maybe not in the this initial Jira. If we police the uniqueness of classification names and existing traits are treated as classifications, that should be fine for migration use cases. If we then add in annotations which are not uniquely named- this gives us clear differentiations between classifications and annotations for the future. I agree we can do a follow on Jira to update the docs. all the best, David From: Nigel L Jones/UK/IBM@IBMGB To: [email protected] Date: 04/10/2016 16:56 Subject: Re: Rename trait to classification On 03/10/2016 11:35, David Radley wrote: > I am not sure I follow your first point. The classification hierarchy I > was thinking of is the classification scheme, which is not flat. Maybe we * I'll try to clarify... Mandy pointed out in an earlier message that classifications may be ordered (for example going from unclassified to top secret) as well as contain subclassifications (the confidential/personal confidential example). We've not discussed ordering yet, but in a policy deployed in ranger I'd like to be logically able to have a condition like "confidentiality >= Confidential". Whilst this could be done (fudged?) with the name, or in the rule using "confidentiality in ('Confidential','Sensitive','Restricted','Top Secret'), if the order is frequently used we need to add the notion of ordering to make rules easier to develop. See also my point below about flattening.. purely as an interim measure. > should consider leaving term classification and term classification > inheritance to a follow on Jira. Agreed - I will open a new jira for my concern, though I was referring to classifications rather than business terms. On another point, you refer in your proposal summary "top level elements like entity and terms" - but terms are implemented as traits today, whilst entities are .. entities. I think we're suggesting classifications are also implemented as a specialization of annotations and thus as traits, so can traits have traits? - my familiarity with the data model/api isnt' developed enough yet... The distinction between entities and traits is getting more blurred - mostly it's the easy association & lack of guid yet in many ways terms may need to become first class entities in their own right? > I agree that changing the existing Ranger tags to sync with Atlas > classifications makes sense to not break existing Ranger integration. Agreed - I suggest that the initial approach focusses on getting the model/api right in atlas, whilst considering that these classifications need to be used flexibly at the point of data access. Ranger initially preserves the simple "tag" approach used today (and must be part of any change in this area to avoid breakage) - perhaps flattening & label modification, and another JIRA is then opened (first here, then ranger) to explore better ways of providing more flexibility in the rules later. Additionally: * Annotations - David you mentioned we may not wish to police uniqueness of annotations. In the existing implementation the name of a trait is unique. I think we would want to keep unique names, even for ad-hoc annotations - though to adopt a fully social model including commenting, voting we may also have to consider visibility of the annotations themselves (I'd be inclined to keep it simple though). I propose we open a social features JIRA to continue that longer termed discussion. * update the docs/wiki to add definitions for entity, term, classification, annotation, trait, classification, classification scheme, classification hierarchy etc. This could also be a sub-JIRA? Nigel. 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
