[
https://issues.apache.org/jira/browse/ATLAS-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026139#comment-16026139
]
David Radley commented on ATLAS-1768:
-------------------------------------
[~mandy_chessell] Thanks for your quick responses. I am left with 2 thoughts :
I am wondering why a sub category life cycle is not tied to the parents. What
is the thinking here? I thought it would be a true tree; so we would stop the
deletion of a parent if it had children or have explicit delete subtree API. I
understand that the child categories could be moved to top level categories if
the parent is deleted; this seems odd, as categories half way down a hierarchy
may not make a lot of sense as top level categories. If this end state is
desired - I suggest the child category should be explicitly moved to the top
prior and this move not occur as part of the parent category deletion. Also for
soft deletes if the children categories are deleted prior to the parent - this
leaves the graph reflecting the before state more accurately as the parent
pointer would still point to the old parent.
I am not seeing where Classifications have cardinality in the current Atlas
model; I only see cardinality around attributeDefs (and soon to be
relationshipDefs). I think adding cardinality to ClassificationDef would be
useful - the Atlas code could then police this constraint.
> Create common types for Open Metadata
> -------------------------------------
>
> Key: ATLAS-1768
> URL: https://issues.apache.org/jira/browse/ATLAS-1768
> Project: Atlas
> Issue Type: New Feature
> Components: atlas-core
> Affects Versions: 0.9-incubating
> Reporter: Mandy Chessell
> Assignee: Mandy Chessell
> Labels: VirtualDataConnector
>
> This JIRA describes a proposal for standard types for open metadata entities
> and relationships. For example, glossaries, database definitions, rules,
> policies, ...
> The value of having standard definitions for metadata is to enable type safe
> APIs and business level UIs plus be able to exchange metadata between
> different instances of metadata repositories.
> The implementation of these common types is divided into 8 areas:
> * Area 0 - for extensions to Apache Atlas's base model
> * Area 1 - for definitions of the data-related assets we are governing and
> using
> * Area 2 - for a glossary of meanings and semantic relationships
> * Area 3 - for information about asset use, crowd-sourced definitions and
> collaboration around the data-related assets
> * Area 4 - for governance such as policies, rules and classifications
> * Area 5 - for reference models and reference data
> * Area 6 - for metadata discovery processes (see
> https://issues.apache.org/jira/browse/ATLAS-1748)
> * Area 7 - for lineage
> Adaptation and flexibility are key in metadata environments so these common
> definitions must be extensible - and we still need to support the ad hoc
> definition of new types in Atlas.
> Apache Atlas supports meta-types that are used in the definition of new
> types. These are currently enumeration, struct, classification and entity.
> JIRA https://issues.apache.org/jira/browse/ATLAS-1690 adds relationships to
> this list. The open metadata models make use of all of these meta-types.
> These are represented by sterotypes on the classes of the open metadata
> definitions.
> The Atlas wiki has the models as a set of linked pages which are probably the
> easiest way to view the models.
> Start here:
> https://cwiki.apache.org/confluence/display/ATLAS/Building+out+the+Apache+Atlas+Typesystem
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
