atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nigel Jones (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ATLAS-1410) V2 Glossary API
Date Tue, 14 Mar 2017 12:02:41 GMT

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

Nigel Jones commented on ATLAS-1410:
------------------------------------

On p6 is the intent that term12 can sit in both glossaries - ie it could for example also
be linked to cat14 in Glossary 2? This makes sense

p7 - How about unicode support for term names ? I think this would be valuable for any displayed
name (and perhaps the description is not enough). Surely we should be able to have for example
a chinese term in the glossary? More restrictive spec for an internal name is then ok

p8 - in figure 3 "hive column" is meant to be an instance - so could be worth using an example
like "employee salary" or similar to avoid confusion with type definitions. Also on this page
it would be worth comparing to the v1 implementation. The association there between the column
(entity) & term (trait) is the trait instance, which also carries additional information
- parameters. That’s how we might capture the level of SPI, whilst I think with this new
design that is done through the hierarchy of glossary terms. An example may help? or just
a link to page 16. Question for other reviewers - is this sufficient (I think it's simpler,
but do we lose additional attributes?)

p13 - Homophones. This gets more complex due to dialect? (I'm not a linguist). It perhaps
brings another dimension - the need for translation of names/descriptions for display purposes

General - it's mentioned search is excluded. Perhaps improved DSL/UI support for glossary
navigation could be the subject of an additional JIRA (revisit later)

p16/17 - Apache ranger integration * We should consider how the existing tag support in ranger
is affected by these changes. Perhaps the simplest suggestion is that the current ranger tagsync
works only with the v1 glossary. Then I propose that for v2 we have a new tagsync which will
navigate the hierarchy to allow ranger (or other enforcement engines) to pick up a simple
entity:classification map as it does today, but using a new "OMAS" API. This will require
an additional Atlas JIRA (to provide the new Governance API) and a ranger JIRA (to consume
that API using a new tagsync process). In those JIRAs we should also update docs to clarify
the interoparability I'll open these shortly.  
 * On a related point, it could be useful to be able to identify a term as "relevant" for
ranger/enforcement engines. This could come from it's membership in a category, or some other
attribute such as a flag. 

Otherwise an excellent proposal and very much needed for Atlas to "step up" to support enterprise
glossaries.

> V2 Glossary API
> ---------------
>
>                 Key: ATLAS-1410
>                 URL: https://issues.apache.org/jira/browse/ATLAS-1410
>             Project: Atlas
>          Issue Type: Improvement
>            Reporter: David Radley
>            Assignee: David Radley
>         Attachments: Atlas Glossary V2 proposal v1.0.pdf, Atlas Glossary V2 proposal
v1.1.pdf
>
>
> The BaseResourceDefinition uses the AttributeDefintion class from typesystem. There are
newer more funcitonal versions of this capability in the atlas-intg project. This Jira is
changing over the glossary implementation to the newer entity / type classes.  
> Instread of the instanceProperties and collectionProperties in the BaseResourceDefintions
we should use something in this sort of style :  
> "
>  AtlasEntityDef deptTypeDef =
>                 AtlasTypeUtil.createClassTypeDef(DEPARTMENT_TYPE, "Department"+_description,
ImmutableSet.<String>of(),
>                         AtlasTypeUtil.createRequiredAttrDef("name", "string"),
>                         new AtlasAttributeDef("employees", String.format("array<%s>",
"Person"), true,
>                                 AtlasAttributeDef.Cardinality.SINGLE, 0, 1, false, false,
>                                 Collections.<AtlasStructDef.AtlasConstraintDef>emptyList()));
>         AtlasEntityDef personTypeDef = AtlasTypeUtil.createClassTypeDef("Person", "Person"+_description,
ImmutableSet.<String>of(),
>                 AtlasTypeUtil.createRequiredAttrDef("name", "string"),
>                 AtlasTypeUtil.createOptionalAttrDef("address", "Address"),
>                 AtlasTypeUtil.createOptionalAttrDef("birthday", "date"),
>                 AtlasTypeUtil.createOptionalAttrDef("hasPets", "boolean"),
>                 AtlasTypeUtil.createOptionalAttrDef("numberOfCars", "byte"),
>                 AtlasTypeUtil.createOptionalAttrDef("houseNumber", "short"),
>                 AtlasTypeUtil.createOptionalAttrDef("carMileage", "int"),
>                 AtlasTypeUtil.createOptionalAttrDef("age", "float"),
> "
> For the parent child relationships with glossary categories and terms we should be able
to have the type system manage edge deletion. As part of this, we will need to investigate
whether we could get rid of the disconnect and connect methods added in ATLAS-1186 
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message