Hello Madhan, This makes sense. The areas that are impacted by this change are the governance and collaboration models which is a new space for Atlas so rework is cheap.
I am happy to go ahead and replace each of the richer classifications and structs in the common model with an entity/relationship combo. This means concepts such as user tags and certifications will be represented by separate entities. If the relationship is defined as a composition, I am assuming that (soft-)deleting the main entity will also delete the minor entity. For example if a DataSet entity that is related to a user tag of "useful" (also an entity) is deleted then the tag entity would also be deleted if the relationship between them is composition. As such we would not get zombie tag entities due to the fact that they are modelled as entities rather than classifications. This is a less explicit model but if it keeps the processing simple in the structs, classifications and relationships as you describe then it is worth it. It also creates a clear definition of when to use a classification or an entity/relationship combo. This is currently a little bit subtle as the classifications become rich :) We would also not need cardinality on the classifications which is less work. All the best Mandy ___________________________________________ Mandy Chessell CBE FREng CEng FBCS IBM Distinguished Engineer Master Inventor Member of the IBM Academy of Technology Visiting Professor, Department of Computer Science, University of Sheffield Email: [email protected] LinkedIn: http://www.linkedin.com/pub/mandy-chessell/22/897/a49 Assistant: Janet Brooks - [email protected] From: Madhan Neethiraj <[email protected]> To: "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Date: 28/06/2017 10:09 Subject: Re: [DISCUSS] Restrict AtlasStruct and AtlasClassification attributes to primitive and enum types Sent by: Madhan Neethiraj <[email protected]> Mandy, The relationship introduced in ATLAS-1690 requires entity-type be specified for each end; effectively injecting an attribute to the entity types specified. This doesn’t allow struct or a classification types at relationship ends. In addition, allowing structs to hold entity references add complexity in dealing with edges, especially considering cases like array/map of structs. None of the existing models use object-reference attributes in structs; and we haven’t come across such use by any one so far – hence this discuss thread to find existing use for structs to hold object references. It will help us understand concrete usecases better and perhaps offer an alternate approach to model the same. Thanks, Madhan On 6/28/17, 12:17 AM, "Mandy Chessell" <[email protected]> wrote: Hello Sarath, These restrictions will have an impact on the open metadata and governance type model - and I expect other models that people have built. The impact of this change is that many of the structs and classifications from the open metadata and governance type model will need to be changed to an entity plus relationship combo, creating overhead and complexity in the model and reducing clarity. Perhaps it would help to explain why these restrictions are needed? Here are some examples The restriction that we can only have one instance of a type of classification associated with an entity is creating a problem for modelling social tagging and assignment of certifications to assets. As such we need to have an array of structs inside these classifications. Each cell in the array represents a user's tag or a certification that the asset has received. In the longer term a better solution to this use case is of course to allow cardinality on the classification Structs and classifications often need to include a relationship. For example, if we use a classification to represent the terms and conditions that apply to an asset - then ideally we would want a relationship to the contract or license type. I am assuming that maps and arrays considered primitive since that will impact the Hive model. All the best Mandy ___________________________________________ Mandy Chessell CBE FREng CEng FBCS IBM Distinguished Engineer Master Inventor Member of the IBM Academy of Technology Visiting Professor, Department of Computer Science, University of Sheffield Email: [email protected] LinkedIn: http://www.linkedin.com/pub/mandy-chessell/22/897/a49 Assistant: Janet Brooks - [email protected] From: Sarath Subramanian <[email protected]> To: [email protected], [email protected] Date: 28/06/2017 02:43 Subject: [DISCUSS] Restrict AtlasStruct and AtlasClassification attributes to primitive and enum types Hello all, As part of the new relationship design (*ATLAS-1690 <https://issues.apache.org/jira/browse/ATLAS-1690>)*, we are planning to restrict AtlasStruct and AtlasClassification types to have attributes of primitive and enum types only. Attributes that refer to entity/entities will no longer be supported for AtlasStruct and AtlasClassification types. Please note that none of the existing out of the box types are impacted by this change. If you have any concerns with this change please let us know. Thanks, Sarath Subramanian
