[
https://issues.apache.org/jira/browse/ATLAS-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15997971#comment-15997971
]
David Radley commented on ATLAS-1690:
-------------------------------------
Thank you very much for the feedback [[email protected]] 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: https://issues.apache.org/jira/browse/ATLAS-1690
> 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
(v6.3.15#6346)
