GASP

Downloads

The GASP Standard as Apache Ossie files

Apache Ossie (incubating) is an open interchange format for semantic models. GASP publishes its ontology, a reference semantic model and the mapping between them in that format, generated from the canonical formulas on every release. All three documents pass the upstream validator and GASP's own cross-reference checks in continuous integration.

Files

  • gasp.ontology.yaml

    Every dataset and GASP concept as an entity type, every field as a value type or relationship, enum values as constraints.

    157 KB
  • gasp.semantic_model.yaml

    Every dataset with its fields as OSSIE_SQL_2026 expressions, the foreign-key relationships between them and every canonical formula as a metric. A formula the model cannot state in one expression is staged through a per-period dataset whose source is the compiled SQL.

    965 KB
  • gasp.mapping.yaml

    The ontology mapped onto the reference model, so a consumer can resolve concepts to datasets and fields.

    86 KB
  • coverage.json

    How each formula was exported: direct with its portability rung and constructs, staged with the reason, or not computable.

    82 KB

What the model covers

The semantic model carries 378 metric entries (each Operating and Market form and each variant is an entry of its own). 194 are direct expressions, 169 are staged and 15 are declared not computable in the standard itself.

A metric is staged when Ossie's metric language cannot yet state it in one expression. The reasons, with the number of entries each one accounts for:

93
period bound in filter
34
at period_start
11
cohort
7
window
6
lag
6
total
4
to_date
4
all_time
2
period_days
1
bucket
1
distinct pair

Each staged dataset carries its source in Postgres, with Snowflake, BigQuery and Databricks sources in the GASP extension, so the metric still runs on each warehouse.

Portability profile

Apache Ossie measures converters on a ladder of fixtures, M0 to M3, each adding one construct. Reading it the other way, each of the 194 direct expressions is tagged in coverage.json with the highest published rung whose construct it needs, so a converter's graded rung says how much of GASP survives it:

0
M0, a bare SUM over one field
51
M2, the core aggregate set (COUNT, COUNT DISTINCT, AVG, MIN, MAX)
143
M3, a filtered aggregate

The rungs above M3 (relationships, metric composition, date scalars, window and offset functions) are announced upstream but not yet published. The constructs they will measure, counted per direct expression (the null guard is the COALESCE around every GASP sum, so a sum over no rows is 0 and no expression is a bare M0 sum):

143
filtered aggregate
126
arithmetic over aggregates
89
null guard
77
count distinct
35
cross-dataset
17
date scalar
10
percentile

GASP writes a filtered aggregate as FILTER (WHERE ...), the form the expression language requires. The upstream M3 fixture uses the CASE WHEN form, so a converter graded at M3 may still need the filter clause; the M3 count above is what that would cost.

Example model

example/ is the Core department on its own, in the layout of the upstream flights example: gasp_saas.ontology.yaml (28 KB), gasp_saas.semantic_model.yaml (143 KB) and gasp_saas.mapping.yaml (8 KB), cut from the full documents above so every statement matches them. It is the draft of the example GASP proposes for the Apache Ossie repository. example/demo/ runs it: a data script, one query per metric and the expected values, for DuckDB or Postgres.

Conformance set

conformance/ holds one worked case per staged reason (11 cases): a complete Ossie model with the staged dataset and its metric, the reference query in Postgres SQL, the expected result as a VALUES list in standard SQL and the fixture rows it reads (9 tables, 4,703 rows, period 2026-01-01 to 2026-06-30). A proposal that adds one of these constructs to the portable language can be tested against the case for it. manifest.json lists every case with its formula, datasets, columns and expected rows.

Validating the files

The documents target Ossie schema version 0.2.0.dev0 and are checked against the upstream validator at commit 99c21c2 (2026-11-02). To check them yourself, from a clone of apache/ossie: 

uv run validation/validate.py gasp.semantic_model.yaml
uv run validation/validate.py gasp.ontology.yaml --schema ontology/ontology.json
uv run validation/validate.py gasp.mapping.yaml --schema ontology/mapping.json

The mapping names the other two documents by relative path, so validate it from the directory that holds all three.

The GASP payloads in each document's custom_extensions are described by the GASP Ossie extension schema, which GASP's own cross-document checks apply to every file it writes.

Source and licence

The files are generated by the gasp-standard-mcp package from the canonical standard and committed under standard/exports/ossie in the public repository, where the distribution plan (docs/ossie-interop-spec.md) and the validator findings are kept. They carry the standard's licence. More on the export and the MCP tools that read the same data.

Try searching for:

↑↓navigate↵select