Hello, @bulky-soccer-26729 suggested to follow-up here with my questions raised in #contribute. We want to contribute by allowing editing of properties for glossary terms in UI. We believe that it's necessary to provide support for restricting data types for property values for particular properties somehow (not supported in DataHub as of now since all properties are

string: string

at the moment), because otherwise the manually edited values would for sure become an unusable jungle rather quickly. Please note that the (optional) type (re)definition should be used when editing properties for datasets from the UI as well, i.e. I don't think that defining a new/different aspect for additional metadata for glossary terms instead of existing properties is the right approach. My questions are related to suggestions regarding how to model the type (re)definition of the particular properties (the default would obviously stay the current

string: string

) and also how to model list of values / enums as possible type definitions / where to put them (as mentioned in the original thread in #contribute, I believe that static configuration of these lists of values should be sufficient, the underlying storage for properties shouldn't change from its original

string: string

definition and it isn't necessary to enforce the defined type in the API and/or during ingestion (at least certainly not in the first step and possibly not at all if this should bring some unwanted incompatibility, etc.). See additional details in the original thread.

@bulky-soccer-26729 Any thoughts here?