Do not prescribe "AI Context" as a key name

[cpimhoff]

The OSI will not be building AI features in the OSI repo; this all happens downstream, and so I don’t think we should be prescribing any aspect of how the data is consumed, including for AI. It'd be like naming a key data_browser_description because we expect some descriptions to appear in data browser UIs.

Every consumer will be experimenting with what context to input into a context window, and constraints around inputing context into LLMs will continue to rapidly change far faster than this working group will handle.

I strongly suggest renaming concepts like ai_context.synonyms to just synonyms. Whether some fields are or are not consumed by AI (and how) is not reasonable for OSI to prescribe at this time.

[rlittle08]

I disagree. I think ai_context is central enough to the core goal of OSI that it warrants its own namespacing. While data_browser_description would be about how to present data to humans in a specific kind of app, ai_context is one layer abstraction higher. I think the key distinction of 'metadata for human eyes' vs. 'metadata for AI' is useful enough to include in the core spec.

That said, I take your point that constraints are moving rapidly, and it's unclear at this point what structure makes the most sense within ai_context.

[cpimhoff]

I don't think separating "context for humans" vs. "context for robots" is really where the puck is going regarding AI consumption. I also do not see how I would instruct a user (or an LLM) authoring content in this specification how to decide what goes in the human_description vs. what goes into the ai_description. But that's not something we'll settle here.

What we can likely agree on is that, practically speaking, the OSI has no plans to own any AI consumption points or training layers. It could absolutely be the case that what we prescribe as ai_context.synonyms ends up being useless to any given AI consumption layer which ingests OSI specs (instead relying entirely on the LLM to internalize synonyms itself), while a BI tool may simultaneously determine ai_context.synonyms is fantastically useful for a simple frontend filter bar. In both of those cases, the ai_context. prefix is categorically misnamed, as the AI consumer isn't using it at all, and a non-AI application is. I don't think those are outlandish cases.

The OSI has lots of difficult problems and concepts to gain critical consensus on. I don't think this is one that's worth the squeeze for us.

[khush-bhatia]

@cpimhoff I agree. But just a generic field "context" does not mean much either. How about we replace ai_context field with synonyms ? There is value for both AI/BI tools to be able to add synonyms for metrics, dimensions, datasets.

[magerdaniel]

I do love the generic field ai_context. I can put there URI's and furhter backround information what the agent can send to the llm. I.e. a ppt where the definition of a metric is explained

[stormrise]

A good semantic should describe by itself.

I think everything related information should put in description.

Descriptions should cover:

• Grain (what each row represents)

• Source

• Business definition / formula

• Differences from similar fields

• Edge cases or filters

• Synonyms/aliases (which alone can replace many uses of ai_context)

not only llm need such info. human also need.