atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Radley (JIRA)" <>
Subject [jira] [Commented] (ATLAS-1690) Introduce top level relationships
Date Fri, 05 May 2017 09:11:04 GMT


David Radley commented on ATLAS-1690:

Thank you very much for the feedback [] and [~cmgrote] . I am very
much looking forward to your responses.

To respond to the Sarath's points : 

1. I do not think we should have "to" and "from". This implies a direction. For bidirection
associations we do not want to imply there is any direction. Aggregations have a containership
relationship - I think the important piece here is the container side of things not the direction.
2. I am wondering about the use case for a relationship to have more than one type. We can
allow more than one type here if there is a compelling use case.
3. Interesting idea. You are right - tag propagation is important. As these are not bidirectional
relationships, there is not an implied direction-it is not obvious which way the propagation
should flow. I could see us wanting to do this sort of thing for composition (which are not
modelled by a top level relationship). I suspect it is less likely that for 2 independent
entities we would want to propagate tags using flags in the types. 
Ideally propagation of tags should be defined in Ranger rules - as we are likely to want different
tag propagation in different contexts. Can I suggest we deal with classification in a subsequent
design? We can then cover Semantic classification which will actually be a relationship. 
4.  Yes this is the same as Suma's suggestion of a category; I was thinking of "bidirectional”,
“aggregation” - as association could be directional and contains could be composition
. I will put this in, as we can then put this value into the edge - so we can identify which
edges we need to expand into attributes. Are you OK with these amendments?  
I am thinking we still need an isContains flag to indicate the container end of a relationship.
On your examples
1. I think a collection to member relationship would be an aggregation. 
2. and 3. are compositions. There is a case to model composition in the top level relationship
as well. I suggest we consider that later to reduce the migration impact of this change. 
4 I have not looked at lineage. 

Responding to Chis's comments 

I can see that tag propagation direction is important; I am not sure the type itself should
have these indicators. In the wider VDC architecture proposed in the Atlas wiki,  the OMRS
would not be responsible for tag propagation. A second layer -the OMAS layer exposes data
in a particular shape for consumption in a context, eg around assets or the glossary or catalog
search. Each of these OMAS layers are likely to have different tag propagation requirements.
I am therefore reticent to have tag propagation at this lower layer. By not propagating at
the OMRS layer classifications are defined once and are not duplicated. As above, I suggest
we enhance the classifications design after the glossary. 

> Introduce top level relationships
> ---------------------------------
>                 Key: ATLAS-1690
>                 URL:
>             Project: Atlas
>          Issue Type: Improvement
>            Reporter: David Radley
>            Assignee: David Radley
>              Labels: VirtualDataConnector
>         Attachments: Atlas_RelationDef_Json_Structure_v1.pdf, Atlas Relationships proposal
v1.0.pdf, Atlas Relationships proposal v1.1.pdf, Atlas Relationships proposal v1.2.pdf, Atlas
Relationships proposal v1.3.pdf, Atlas Relationships proposal v1.4.pdf, Atlas Relationships
proposal v1.5.pdf, Atlas Relationships proposal v1.6.pdf, Atlas Relationships proposal v1.7.pdf
> Introduce top level relationships including support for 
> -many to many relationships
> - relationship names including the name for both ends and the relationship.

This message was sent by Atlassian JIRA

View raw message