[
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)
