Repository navigation
[core-spec] Add Relational Query Interface specification - #354
justint-db wants to merge 2 commits into
Conversation
Adds core-spec/relational_semantics.md, a draft specification for querying Ossie semantic models through SQL extended with measure semantics -- Layer 2 of the layered query interface (the Relational Interface).
Syncs the relational_semantics.md spec with the upstream draft, adding Appendix D relating the design to Hyde and Fremlin's Measures in SQL.
christianeu-db
left a comment
christianeu-db
left a comment
There was a problem hiding this comment.
For this spec, it would be good to state how this fits in with OSSIE_SQL_2026 (e.g. the query complement to the expression language) and an initial subset of SQL that MUST be supported by vendors to be compliant with Layer 2 OSSIE_SQL_2026
| MEASURE(s.ticket_count), | ||
| MEASURE(o.total_revenue) / MEASURE(s.ticket_count) AS revenue_per_ticket | ||
| FROM model.orders o | ||
| JOIN model.support s ON o.customer_id = s.customer_id |
There was a problem hiding this comment.
If all the underlying datasets were in a a single model, no joins would be necessary. This example seems to be about two different models, is that correct?
Does the spec describe valid interactions between two different models?
|
|
||
| ### 7.6 JOIN | ||
|
|
||
| A measure relation MAY be joined to any relation using any join type (INNER, LEFT, RIGHT, FULL |
There was a problem hiding this comment.
consider the case where the model, as well as the (perhaps the same) underlying physical tables are exposed to the BI tool. Model provides a safe way to join the tables. This proposal says that model can be joined with regular tables as well. Would that produce correct results in all cases?
3 participants
Summary
Adds the Relational Query Interface specification to
core-spec/asrelational_semantics.md. It defines Layer 2, the Relational Interface of the layered Ossie query interface: how a semantic layer exposes an Ossie model to SQL-native BI and AI tools as a set of related SQL relations, and the semantics and correctness guarantees of querying the model's measures through ordinary SQL.Grounded in Hyde and Fremlin's Measures in SQL (https://arxiv.org/abs/2406.00251), a measure is a column evaluated by a
MEASURE()aggregate. A tool writes the SQL it always would and substitutesMEASURE(name)for a raw aggregate; the engine evaluates each measure at its own grain, so results stay correct across joins, filters, and grouping.It realizes two Ossie design proposals: the BI-Semantic Layer Interface and the Layered Query Interface. It is the "semantics of a layer" companion foreshadowed in #344, sits alongside the foundational semantics in #246, and builds on the dataset-scoped metrics proposed in #343.
Related Issues
Related: #246, #343, #344.
Checklist
Specification
core-spec/and follow the existing structuredev@ossie.apache.org; on-list discussion of its contents is still to comeOntology
ontology/are consistent with spec changes — N/A, no ontology changeConverters
converters/is updated to reflect spec or ontology changes — N/A, no converter changeValidation
validation/are updated if the spec changed — N/A, no schema/validation changeDocumentation
docs/is updated to reflect any user-facing changes — N/A, the change is itself a spec documentCONTRIBUTING.mdis updated if the contribution process changed — N/AExamples
examples/are added or updated for any new spec constructs or converter support — N/A, no new constructs requiring example modelsTests
pytest/ CI green) — N/A, documentation only, no codeCompliance
AI disclosure
Per the ASF Generative Tooling Guidance, this contribution was prepared with AI assistance. All specification decisions and design choices are mine. I have reviewed and verified every change.