dengc367 commented on PR #14239:
URL: https://github.com/apache/gravitino/pull/14239#issuecomment-6494252536
Thanks for the detailed replies — taking them in order.
**`TermConceptRef`**: agreed, it stays here. I have now specified it rather
than only describing it: `{ termName, ontology, concept, iri? }`, stored on the
term side, unique per `(term, ontology, concept)` with idempotent re-adds, no
document position or version so a re-version does not break it, validated at
write time against the version the caller can read (a `DRAFT` ontology only for
a caller who can see it), and a later version that drops the concept leaves the
reference readable but unresolved instead of cascading. Dropping an ontology
while references exist conflicts. So the glossary side only needs the list on
the term resource plus "edit privilege on the term, visibility of the ontology".
**Status**: noted — our design now records that the two documents agree on
the split (three states where each item is reviewed, two where the whole
vocabulary or domain is published), so it does not read as an accidental
difference.
**Privileges**: agreed the names settle with the Domain design. From this
side the family name is orthogonal to the governance shape: coarse `MANAGE_*` /
`USE_*` for a container a few stewards maintain, finer `CREATE` / `USE` /
`MODIFY` plus owner for crowd-contributed content — that argument holds whether
the family is called `*_DEFINITION` or `*_ONTOLOGY`. If the Domain design picks
the general names, the ontology takes them with the same meaning; our access
control section now says so.
**Grant placement**: a vocabulary lives only at the metalake, so metalake
plus ontology grants are enough and there is no per-domain level to mirror. The
"can create but cannot approve" gap you describe does not arise for a
vocabulary, since it has no per-item approval step. If the general family
lands, the ontology is the coarse-granted member of it.
The design changes are in 99533b24e on #14310.
--
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]
