Hi Adam, Dmitri, Yufei, Adding in a clarification: I believe "first class" in the context of OSI would mean that it is given the same level of importance as a Polaris entity as a Table or View would. Is that generally correct?
Best, Adnan Hemani On Mon, Jun 22, 2026 at 10:50 AM Adam Christian < [email protected]> wrote: > Hi Dmitri, > > This proposal [1] includes a second tab with the detailed design. It shows > the REST APIs that handle the CRUD operations for OSI Semantic Models. The > Semantic Model will be validated in the OsiDocumentValidator which I assume > will validate against the Apache Ossie version. In my reading, Polaris does > not control it; we will leverage the upstream spec. > > Regarding OSI functionality if this feature is always active, I assume > users would benefit from it being active. If an admin user does not want to > leverage OSI inside their Polaris instance, they simply won't grant the > privileges to the consuming users. > > [1] - > > https://docs.google.com/document/d/1ZdI-1w_5LbyCMhvUhLCtOt-N1Z89L2P-oiGLaYayCZg/edit?usp=sharing > > On Thu, Jun 18, 2026 at 6:13 PM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi Yufei, > > > > Sorry for getting to this proposal late. I postred some comments on PR > > 4816, recounting the key points here in more detail. > > > > * From the proposal doc: Goal G1: "Store OSI 0.1.x documents as > first-class > > Polaris entities, scoped under a Namespace" > > > > I believe this needs a bit more discussion before we proceed to concrete > > code changes. The idea of persisting OSI data is totally valid. However, > > I'm not sure what "first class" means in this context? Does it mean that > > OSI functionality has to be active all the time? > > > > My initial perception of this proposal is that as a use case it is > similar > > to persisting Metrics (or Events) in Polaris. That is, the feature is > > valuable, but downstream projects may want to have the flexibility of > > deciding whether to include it or not. > > > > * Another point I'd like to clarity is about the REST API definition. Are > > API endpoints going be defined and controlled by the Polaris project? > > > > * Are REST API payload types defined and controlled by Polaris or by > Apache > > Ossie [1]? > > > > [1] > > https://www.mail-archive.com/[email protected]/msg86564.html > > > > Thanks, > > Dmitri. > > > > On Fri, May 29, 2026 at 6:34 PM Yufei Gu <[email protected]> wrote: > > > > > Hi folks, > > > > > > As AI agents, BI tools, notebooks, and query engines increasingly > consume > > > the same data, semantic definitions such as metrics and dimensions are > > > often duplicated across multiple systems. This leads to inconsistent > > > definitions, duplicated effort, and governance challenges. The rise of > AI > > > agents further amplifies this problem, as agents rely on semantic > context > > > to understand data and reason about business concepts. Without a shared > > > semantic layer, organizations often end up maintaining multiple > versions > > of > > > the same business definitions across tools and applications. > > > > > > JB and I would like to start a discussion on adding semantic layer > > support > > > to Apache Polaris so semantic models can be defined once, governed > > > centrally, and consumed consistently across tools. The proposal[1] > > > introduces semantic models as a first class Polaris entity using the > Open > > > Semantic Interchange (OSI)[2] specification[3]. At a high level, the > > > proposal adds: > > > > > > - A new SEMANTIC_MODEL entity type > > > - CRUD APIs for semantic models > > > - Schema validation and authorization > > > > > > Polaris remains a metadata service and does not execute metrics or > > semantic > > > queries. > > > Feedback on the overall direction, design, and OSI adoption would be > > > greatly appreciated. > > > > > > 1. > > > > > > > > > https://docs.google.com/document/d/1ZdI-1w_5LbyCMhvUhLCtOt-N1Z89L2P-oiGLaYayCZg/edit?usp=sharing > > > 2. https://open-semantic-interchange.org > > > 3. > > > > > > > > > https://github.com/open-semantic-interchange/OSI/blob/main/core-spec/spec.md > > > > > > > > > Yufei > > > > > >
