Hi Adam, Let me clarify my points about "first-class" and "always active".
I certainly support running the OSI API in Apache Polaris build by default. However, from the downstream user's perspective, I believe the code should be modularized to allow custom builds to select only the APIs they really need to include. This also relates to exposing the OSI endpoints in the IRC config API [1]. I propose following the approach developed under the Metrics API PR [4115]. [1] https://lists.apache.org/thread/bov6nhryqjmtrxw5nxhss0o0c4ntn6o0 [4115] https://github.com/apache/polaris/pull/4115 Cheers, Dmitri. On Mon, Jun 22, 2026 at 1:50 PM 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 > > > > > >
