[
https://issues.apache.org/jira/browse/ATLAS-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15931905#comment-15931905
]
Stefhan van Helvoirt commented on ATLAS-1410:
---------------------------------------------
Page 5:
Use case 1: "It is important that duplicate glossary terms names can be defined
in the glossary", No. Within a single glossary, it should not be possible to
have multiple terms with identical names. If the requirement arises to maintain
duplicates then this should be done across multiple glossaries. This is in
alignment with the idea of having 'departmental glossaries'.
Use case 2: There might be a need to have two different types of
categorizations. One for scoping / context and another for adding generic
characteristics on the set of contained terms. In other glossaries this is
sometimes referred to as a Parent Category and Referencing Categories. Each
term has only one Parent Category but could be referenced by multiple other
categories. These referencing categories have a scoping purpose, while the
parent category could also have tags / characteristics that will be inherited
to the contained terms.
Page 6: Regarding discussion point 'There does not appear to be a need for a
Glossary Term to have a special “parent” category, as the Glossary owns the
Glossary Term' If you want to manage a collection of terms in a similar way
within a glossary then some form of parent category or unique structuring
method is needed. If there is no uniqueness then multiple groupings with
different characteristics can collide.
Page 7: "Glossary Term names might not be unique in a Glossary." No, see
earlier comments.
"This is a name containing a term’s
inheritance and the Glossary it comes from." Only Glossary + Term name should
be sufficient, no need to add parent terms in the fully qualified name.
Unclear why there is a need to have different term types. From a business
perspective there is only one type of term. These various types such as Concept
and Attribute suggest something technical which is not relevant from a term
perspective as they are written from a business view. Also, a term can be a
concept in one context and a attribute in another, how is that handled with
this setup? E.g. 'Email address' is a attribute of 'Customer' and a Concept in
the structure 'Location' --> 'Address' --> 'Electronic address' --> 'Email
address'.
Page 8 "A Classification points to one entity and can have many associated
term." I don't think i fully understand this statement. It would be wiser to
have the classification point to one or more terms and that the term will point
to one or more entities. To be further discussed. Also it should be possible to
have multiple classification pointing to the same object.
Page 9 "The classification associated with the term should not be automatically
cascaded by Atlas to the assigned assets." Agree that Atlas does not
necessarily needs to do the cascading because logic might need to be involved.
However, the result might need to be made available in Atlas and shown in a
distinct way. If Atlas is seen as the single source of truth then it must be
possible for a end user to see from solely Atlas that a classification is
'Derived from'. How that derivation has occurred can happen by a different
service.
Stopped after page 11. Will continue to review remaining pages in the coming
days.
> 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)
