yuqi1129 commented on PR #14239: URL: https://github.com/apache/gravitino/pull/14239#issuecomment-6492813996
@dengc367 Thanks for aligning the ontology design with this one, and for the careful check. Replies to both comments below. The doc changes are in 7924b25cc5. **Your first comment** 1. **Privileges**: see point 1 and point 3 below. 2. **Status vocabulary**: see point 2 below. 3. **`TermConceptRef`**: I suggest keeping it in your document. It links a term to an Ossie concept, so it belongs to the ontology side. The glossary design will only reference it. Deferring it until this design lands is fine with me. **Your second comment** 1. **`*_DEFINITION` privileges**: you are right that they are not in `Privilege.java`. They are new privileges proposed by this design. The Access control section says "three new `Privilege.Name` values". The sentence about "the 2.0 privilege model" was in an older version and was removed on Oct 28, so the current doc does not build on any unlanded scheme. On the names: both choices work for me. General names let other business-definition objects reuse them. `CREATE_TERM` / `USE_TERM` / `MODIFY_TERM` + `OWNER` follows the Semantic Model shape that already exists. I will settle this together with the Domain design (#13867). Open Question 2 now lists both options. 2. **Three states**: agreed. The Status section now says why: a term is reviewed one by one and can stay readable after it is deprecated, while a domain or an ontology is published as a whole, so `DRAFT` / `PUBLISHED` is enough there. 3. **Where the privileges are granted**: this is the second part of Open Question 2. One cost of granting term privileges on the metalake only: on a domain there would be no way to say "can create but cannot approve". A Sales analyst who needs to create terms would get `CREATE` on the whole metalake. I would like to decide this after the Domain design lands. Open Question 2 now lists both options and this cost. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
