[ https://issues.apache.org/jira/browse/ATLAS-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15927857#comment-15927857 ]
Mike Nicpan commented on ATLAS-1410: ------------------------------------ Comments on v1.1 ad. Use Case use case 1 It shouldn't be possible to define two terms with exactly the same name. It can be possible to do it only through synonyms if definition stays the same. If we have different definition then we also must have different name for each term. If we will allow same naming we will probably enormously stress glossary integrity. use cases 2 and 3 I agree that Categories are needed to give more control over terms organization but I think I need a bit more thinking if categories should help in creating hierarchies. It might be the case but then we should allow terms to only be leaves and every kind of grouping should be done via category. This would mean that categories should also have classifiers. use case 7 Do you mean collections ? use case 11 this sounds a bit to high level and would probably be nice to describe it in more details I'm explicitly missing two things: 1. ability to inherit classifiers 2. are there any models between terms and assets or is it only about term to asset ? we might want to include couple of levels of models (like LDM and/or PDM for particular technology) at least one is already there - by connecting terms to other terms we are creating concepts which should be visualized in some way for easier navigation ad. discussion point on p. 5 yes, that's how I also see it - Taxonomy is the name of the hierarchy of Glossary Categories but does this mean that Taxonomy is a name of Glossary instance ? ad. Glossary Terms and Glossary Categories discussion point - can there be a term without Category ? if not will there always be at least one prime category for each Glossary ? if yes what is the difference then between Glossary and prime category ? is there any at all ? point for discussion - should it be allowed that term from one Glossary is inside Category from another Glossary ? I think we should not allow this kind of situations as those increase the risk of loosing integrity for particular Glossary. I'd say that there should be a copy of that term done to the other Glossary with some kind of a marker "inspired by". Otherwise we will create tight connection between two Glossaries and their maintenance will be more difficult (e.g. upgrades). ad. Glossary Term identification and names Glossary Term names might not be unique in a Glossary. For example, there could be 2 definitions of customer. - just NO :) "we do not allow 2 Glossary Terms of the same name inheriting from a parent Glossary Term" - so we do allow or not ? or I missed something ? I need an example for this one to properly understand it. ad. Glossary Term context I'd like to create clear distinction between what is here meant by context and the term business context (being a term to term relations that create business context) - I just don't like using word "context" for both. ad. page 9, example In general I do agree with the line of thinking but I have a question: both customer and attributes are terms right ? if so then is "has-a" relationship the best one to do term-to-term assignments ? ad. Owning relationships this "Concept Glossary Terms own Attribute Glossary Terms." I've some doubts about (see above remark for page 9, example) I not saying not go there, I just want to explore it more to understand it better ad. Discussion point – maybe we should consider defining the Glossary Term attributes using the type system rather than relationships - yes we should ad. Discussion point: we could add homophones as well – if there was a need. I don't think there is a need now to do that. ad. Discussion point preferred-term attribute could be stored in the entity, AtlasObjectId or classification. I suggest storing it in the entity. I agree. ad. Discussion point: We will enable collection types to be created. Additionally, we may want to consider including a Collection type that has one attribute called contents with multiple values of the top-level type. Do you mean nesting Collections ? ad. Discussion point Introduction of bidirectional relationships, could be done separately from the Glossary enhancement. We may take a step-by-step approach but I'd say we need this from nearly the very beginning. ad. Discussion point: We may wish to take a more revolutionary approach and allow relationships to be defined as top level artifacts, of which classifications are a type. Can we explore it more ? Sound pretty ambitious and worth to do but let's list consequences. > 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)