[I] [REST] First-class Tag concept in Iceberg REST Catalog [iceberg]

["flyingImer (via GitHub)" <gi...@apache.org>]

flyingImer opened a new issue, #16165:
URL: https://github.com/apache/iceberg/issues/16165

   ### Proposed Change
   
   **Context**
   
   New to the Iceberg community, actively contributing to Polaris OSS on tagging. This issue opens a discussion on standardizing a first-class Tag concept in the REST Catalog spec, complementary to the in-flight read-restrictions and labels proposals. A discussion thread will follow on the dev list.
   
   **Summary**
   
   Add a first-class Tag entity to the Iceberg REST Catalog spec. Tags have identity (name + namespace) and optional schema (allowed values, inheritability). Tag attachments carry a value and are applied to tables, columns (via field-id), views, and namespaces.
   
   **Scope**
   
   - Tag entity CRUD at namespace level
   - Tag attachment management: attach, detach, reverse lookup, dedicated retrieval endpoint
   - Normative behavior contracts: privilege enforcement, visibility filtering, rename atomicity
   
   **Goals**
   
   - Provide a portable classification primitive across catalogs so governance tooling, AI agents, FinOps dashboards, and discovery surfaces integrate once, not per catalog
   - Cover the cross-vendor convergent pattern: Snowflake, Unity Catalog, BigQuery Data Catalog, Atlas, Ranger, Gravitino, DataHub
   - Serve multiple use cases: governance classification, ownership, FinOps, AI and semantic hints, data discovery
   - Complement read-restrictions as the classification input side of the governance pipeline (tag is input, read-restrictions is output)
   - Coexist with labels without conflict: different problems, different tools
   
   **Non-Goals**
   
   - No changes to Iceberg table format files
   - No typed multi-field per-attachment value schema (Atlas and BigQuery advanced usage; addable non-breaking later)
   - No Governed-vs-Standard type system (UC's pattern; expressible via configuration rather than a type split)
   - No tag-to-policy binding wire format (belongs in a separate Policy authoring phase)
   - No LoadTableResult changes (tag attachments retrieved via dedicated endpoint)
   
   **Relationship to existing work**
   
   - Read-restrictions proposal (in flight): delivers enforcement to engines. Tag handles classification management. Together they form a governance pipeline.
   - Labels proposal (#15521): generic catalog-managed metadata channel. Tags have identity and lifecycle; labels are ephemeral annotations. The two solve different problems.
   
   **Next Steps**
   
   - Full design document to follow: wire shape, behavior contracts, cross-catalog interoperability analysis
   - Seeking input from community reviewers, especially contributors outside Polaris
   - Looking for co-champions from catalog implementations interested in cross-catalog validation
   
   ### Proposal document
   
   To be added (design document in progress).
   
   ### Specifications
   
   - [ ] Table
   - [ ] View
   - [x] REST
   - [ ] Puffin
   - [ ] Encryption
   - [ ] Other


-- 
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: issues-unsubscribe@iceberg.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org

Re: [I] [REST] First-class Tag concept in Iceberg REST Catalog [iceberg]

["github-actions[bot] (via GitHub)" <gi...@apache.org>]

github-actions[bot] commented on issue #16165:
URL: https://github.com/apache/iceberg/issues/16165#issuecomment-6430583367

   This issue has been automatically marked as stale because it has been open for 180 days with no activity. It will be closed in next 14 days if no further activity occurs. To permanently prevent this issue from being considered stale, add the label 'not-stale', but commenting on the issue is preferred when possible.


-- 
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: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org