A Dawiso data product is built on two open standards, each covering a different layer. The Open Data Product Specification (ODPS) describes the product; the Open Data Contract Standard (ODCS) describes its contracts. Because the Dawiso Unified Data Product Model follows both, a product can be expressed — and exported — as an ODPS product or an ODCS contract without reshaping anything.
This page is a summary map: where each part of a Dawiso data product corresponds to each standard. For the reasoning behind using the two standards together, see Built on open standards. For the full attribute list behind each object, see Object types and attributes.
Which standard covers what
| Standard | Layer | Covers |
|---|---|---|
| ODPS v4.1 (opendataproducts.org) | The product | Identity, value proposition, ports, SLAs, quality, pricing, licensing, and lifecycle status |
| ODCS v3.1.0 (Bitol, bitol.io) | The contract | The schema, quality checks, servers, access roles, and support behind a single agreement |
A data product expresses as one ODPS product; each of its contracts expresses as its own ODCS document.
How Dawiso concepts map
| Dawiso concept | ODPS v4.1 (product) | ODCS v3.1.0 (contract) |
|---|---|---|
| Data product | Product details — ID, description, value proposition, visibility, version, status | Referenced, not duplicated |
| Domain | — | domain |
| Output port | Data Access | — |
| Input port | Input Ports (Dawiso extension) | — |
| Management port | Management Ports (Dawiso extension) | — |
| Use case | Use Case | — |
| SLA and its dimensions | SLA | SLA Properties |
| Data quality and its dimensions | Data Quality | Quality (per schema field) |
| Pricing plan | Pricing | Price |
| License | License | — |
| Data holder | Data Holder | — |
| Payment gateway | Payment Gateway | — |
| Product strategy and KPIs | Product Strategy | — |
| Data contract | Contract pointer | The document itself — ID, version, description, tags |
| Schema object and fields | — | Schema and Properties |
| Server | — | Servers |
| Access role | — | Roles |
| Support channel | — | Support |
| Team and members | — | Team |
Service levels and quality sit in both layers, on purpose. ODPS carries product-level SLA and quality as headline commitments; ODCS carries them inside the contract, tied to the schema. Dawiso keeps both, so the product advertises its guarantees and the contract makes them precise.
Conventions that make the mapping work
Four conventions do most of the work:
- Name is the object’s name. Both standards require a
name. Dawiso always fills it from the object’s built-in name, so it is never empty. - Status is the workflow state. The ODPS
status(announcement → retired) and the ODCS status (proposed → retired) are not typed-in fields — they are the object’s workflow state, mapped one-to-one by dropping the internal prefix (dp_productionbecomesproduction). - Ports replace ODPS “Data Access.” ODPS models a single, output-only Data Access. Dawiso replaces it with three typed ports: an output port maps back to Data Access, while input and management ports are Dawiso extensions. Typed ports are what make cross-product lineage possible.
- The contract is its own document. In an ODPS export the product only points at its contract; the full contract exports separately as an ODCS document.
What stays in Dawiso
A few things have no place in either standard and stay in the catalog:
- Ownership roles. Owner, Steward, Custodian, SME, and Producer are relationships between people and objects, not product fields, so they do not appear in the ODPS or ODCS output. The organizational holder does map (ODPS Data Holder, ODCS Team), but the role assignments themselves stay in Dawiso.
- Classification. PII Level and Confidentiality, and the code lists behind them.
- Catalog structure. Spaces, applications, decision logs, and virtual assets.
Because the mapping holds in both directions, expressing a product in either standard is lossless for everything the standards model — and the Dawiso-only concepts above are additive, never in conflict.