atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deirdre Clyne (JIRA)" <>
Subject [jira] [Commented] (ATLAS-1410) V2 Glossary API
Date Wed, 29 Mar 2017 18:58:41 GMT


Deirdre Clyne commented on ATLAS-1410:

David, I just reviewed the V1.3 and the document is shaping up well. I have a couple of comments
- the first is this idea of having two terms with the same name in the same workspace. Your
example of this regarding replacement prompts the question - is this a response to not having
a versioning solution and thus adding complexity instead of handling the workflow issue around
changing a definition? If we think there are other reasons for having non unique term names,
how do we understand their separate contexts or decide which to use when?
My 2nd comment is around the use of the word taxonomy. We have the term glossary to describe
a set of terms and categories around a line of business or other grouping. What would the
definition of a taxonomy be to differentiate it from a glossary? We should only use the two
terms if we define them differently and if they each have a different purpose. 

> V2 Glossary API
> ---------------
>                 Key: ATLAS-1410
>                 URL:
>             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, Atlas Glossary V2 proposal v1.2.pdf, Atlas Glossary V2 proposal v1.3.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,
>                         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,
>                 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

View raw message