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
    
    
    


Reply via email to