Mailing-List: contact dev-help@atlas.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@atlas.incubator.apache.org
Date: Wed, 7 Jun 2017 14:30:18 +0000 (UTC)
From: "Nigel Jones (JIRA)" <jira@apache.org>
To: dev@atlas.incubator.apache.org
Message-ID: <JIRA.13069483.1493996838000.18738.1496845818391@Atlassian.JIRA>
In-Reply-To: <JIRA.13069483.1493996838000@Atlassian.JIRA>
References: <JIRA.13069483.1493996838000@Atlassian.JIRA> <JIRA.13069483.1493996838597@jira-lw-us.apache.org>
Subject: [jira] [Commented] (ATLAS-1768) Create common types for Open
 Metadata
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 07 Jun 2017 14:30:23 -0000


    [ https://issues.apache.org/jira/browse/ATLAS-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16040963#comment-16040963 ] 

Nigel Jones commented on ATLAS-1768:
------------------------------------

Is it still the intent that a classification's supertype could be used to scope what a classification is used for (something previous mentioned)

For governance action framework OMAS we need to somehow scope the setup of resources, classifications & the assignments between the two that are used for enforcement. Today Ranger (well actually tagsync) will pull all classifications that relate to 'interesting' entities (hive table etc... encoded in ranger source, albeit via modules... ). 

In gaf omas ( ATLAS-1696 ) we could retrieve only classifications that inherit from a particular supertype (or set of), such as security classification' - as there may be many different kinds of classification we end up using

Is this how you see the model working in terms of what classifications are relevant to an enforcement engine such as ranger (I'll post separately about other scoping mechanisms)


> 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: OpenMetadata
>
> 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)