catpineapple opened a new issue, #155: URL: https://github.com/apache/doris-mcp-server/issues/155
## Motivation Doris MCP Server can expose physical database metadata and support NL2SQL workflows, but schemas and comments do not fully capture governed business meaning. Terms such as “revenue,” “active customer,” or “order date” may have canonical formulas, synonyms, join paths, aggregation grain, filters, and time semantics that cannot be inferred reliably from table and column names alone. As a result, different prompts, models, or clients can generate different SQL for the same business question. The SQL may be syntactically valid while its meaning drifts from the intended business definition. Could we discuss adding optional support for [Apache Ossie (incubating)](https://github.com/apache/ossie) as semantic grounding for NL2SQL? Ossie provides a vendor-neutral, JSON/YAML-based specification for exchanging semantic models across analytics, AI, and BI tools. Its model can carry datasets, fields, metrics, relationships, and AI-oriented context such as synonyms and instructions. Integrating it here would mean consuming and exposing governed semantic metadata to MCP clients; it would not replace Doris as the query engine or make Ossie a complete NL2SQL runtime. ## Possible MVP Start with a small, opt-in proof of concept: 1. Load one or more local Ossie YAML/JSON model files; keep the current behavior unchanged when the feature is disabled. 2. Validate models against Ossie’s machine-readable schema at startup and return actionable errors. 3. Resolve Ossie sources to Doris catalogs, databases, tables, columns, or views, and detect missing or stale mappings. 4. Expose a compact, permission-aware MCP surface, for example: - semantic-model resources; - tools such as `list_semantic_models` and `get_semantic_context`; and/or - an NL2SQL prompt that combines relevant Doris schema metadata with selected Ossie metrics, relationships, synonyms, and AI instructions. 5. Include provenance in the result: the semantic model/version and objects used to produce the SQL, plus warnings for unresolved or ambiguous mappings. 6. Add an evaluation set comparing schema-only and semantic-grounded NL2SQL on metric selection, join correctness, filter/time interpretation, consistency across paraphrases, executable-query accuracy, latency, and token overhead. An adapter boundary may be preferable: Doris MCP Server would consume the Ossie interchange format and provide Doris-specific resolution, while avoiding ownership of a full semantic-model runtime. ## Expected benefit A shared semantic model could ground metric formulas, aggregation grain, valid join paths, dimensions, default filters, business terminology, and logical-to-physical mappings. Agents and BI tools could then reuse the same definitions instead of maintaining separate prompt-specific semantics. ## Risks and tradeoffs - The current Ossie core specification is a draft and may evolve before a stable release. - Doris-specific expressions may require a custom extension or upstream Doris dialect support in Ossie. - Semantic models can become stale relative to live Doris schemas, so validation, versioning, cache invalidation, and hot reload need clear behavior. - Large models can increase prompt size and latency; relevant context should be selected rather than injected wholesale. - Semantic metadata must respect Doris RBAC/OAuth boundaries and must not reveal objects or definitions a user cannot access. - Multiple or conflicting models could introduce ambiguity instead of reducing it. - This should not replace Doris catalogs, query execution, RBAC, or existing SQL security checks. ## Questions for discussion 1. Should Ossie support live inside Doris MCP Server, or in a separate client-side/semantic-layer adapter? 2. Which MCP primitive fits best: resources, tools, prompts, or a combination? 3. Which Ossie subset would provide the most value first: metrics, dimensions, relationships, filters, business terms, or AI context? 4. Should semantic metadata only guide prompts, or should some constructs compile deterministically into SQL? 5. How should Ossie sources and expressions map to Doris multi-catalog objects and SQL dialect behavior? 6. How should semantic metadata be filtered so it never bypasses Doris authorization boundaries? 7. What benchmark and acceptance criteria would demonstrate that the integration actually reduces NL2SQL semantic drift? 8. Would maintainers be open to an opt-in PoC before deciding on long-term support? References: - Apache Ossie: https://github.com/apache/ossie - Ossie core specification: https://github.com/apache/ossie/tree/main/core-spec -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
