Built on open standards

The Data Product Standard application implements open industry standards, so the data products you describe follow portable, widely adopted conventions and can be exported to standard formats. The application combines three standards — the Open Data Product Specification (ODPS), the Open Data Contract Standard (ODCS), and Data Mesh ports. This article explains what each one contributes and how Dawiso brings them together.

The standards at a glance

No single standard covers a data product end to end. Each is strong in its own layer and leaves a gap the others fill, which is why Dawiso combines all three.

Each standard is strongest in one layer and leaves a gap the others fill:

• ODPS describes the product as a business offering — its value, terms, and service levels — but does not model a contract’s schema in depth, nor the typed interfaces that lineage needs.
• ODCS describes the contract and its schema precisely, but not the product around it as a discoverable, priced offering.
• Data Mesh contributes the typed input and output ports that neither ODPS nor ODCS fully specifies — and those ports are what make product-to-product lineage possible.

Dawiso takes ODPS as the base and fills each gap with the standard best suited to it.

Why build on open standards

A data product described to an open standard can be understood, exchanged, and validated by any tool that supports the same standard. That keeps your products interoperable, instead of trapped in a proprietary, one-off model. The conventions are also documented and versioned outside Dawiso, so their meaning does not depend on one vendor.

Open Data Product Specification (ODPS)

The Open Data Product Specification (ODPS) is published by the Open Data Product Initiative at opendataproducts.org, and has been hosted by the Linux Foundation since 2024. Version 4.1 is the base standard the application builds on. It describes a data product as a business offering, not a raw dataset.

ODPS covers the product, commercial, and service layer:

• The data product itself and the domain it belongs to.
• The use cases the product supports.
• Pricing plans and licenses.
• The data holder — the organization that provides the product.
• Service-level agreements (SLAs) and data quality commitments.
• Product strategy and key performance indicators (KPIs).

Dawiso adopts ODPS as the foundation for how it models a data product.

ODPS is one member of a wider family from the same initiative. Open Data Product Catalogs (ODPC) organizes products into portfolios and use cases, Open Data Product Graphs (ODPG) links them to business objectives and KPIs, and Open Data Product Vocabulary (ODPV) keeps terms consistent across the family. ODPS itself stays focused on describing a single data product, which is the layer Dawiso implements.

Open Data Contract Standard (ODCS)

The Open Data Contract Standard (ODCS) comes from Bitol (bitol.io) and is the standard for data contracts, at version 3.1.0. Where the Specification describes the product, ODCS describes the data contract and its schema in detail. Dawiso uses Bitol’s contract standard, not Bitol’s separate data-product standard.

ODCS covers the contract and schema layer:

• Schema objects — the logical tables the contract defines.
• Schema properties — the columns within each schema object.
• Servers — the physical locations where the data lives.
• Quality checks — rules that validate the data against the contract.
• Roles — who can access the product and at what level.
• Support channels — where consumers get help with the product.

Dawiso adopts ODCS for the contract layer, and can export a product and its contract to ODCS format.

Data Mesh ports

Data Mesh, the architectural approach to decentralized data ownership, contributes the idea of typed ports. A data product exposes and consumes data through explicit, named interfaces rather than ad-hoc connections.

Dawiso implements three directional ports:

• Output port — exposes the data a product publishes for others to consume.
• Input port — consumes data from another product’s output port.
• Management port — handles management and control of the product.

For how output and input ports link products into data product lineage, see Data product ports.

How Dawiso combines the standards

Dawiso layers the three standards so each one covers what it models best:

Layer	Standard	What it covers
Product, commercial, and service	ODPS	Product, domain, use cases, pricing, license, data holder, SLA, data quality, strategy, and KPIs
Data contract and schema	ODCS	Contract, schema objects and properties, servers, quality checks, roles, and support channels
Typed interfaces	Data Mesh and ODCS ports	Output, input, and management ports that carry lineage

Two design choices adapt the standards to Dawiso:

• The single “data access” interface defined by ODPS is replaced by the three typed ports. Because each port names a specific output and the input that points to it, Dawiso can draw product-to-product lineage.
• Product and contract status are modeled as Dawiso workflow states rather than plain attributes, so a product moves through a governed lifecycle instead of carrying a free-text status field.

The result is the Dawiso Unified Data Product Model: one model covering a data product end to end, in which every field traces back to a published standard. It is not a standard in its own right, and it adds no proprietary layer — any product described in Dawiso exports back to ODPS or ODCS and validates against the official schema. That is what keeps a product portable: there is no Dawiso-specific model to migrate off later.

For where each part of a data product lands in each standard, object by object, see Standards field mapping.

Exporting to standard formats

Because the model follows ODPS and ODCS, you can export a data product and its contract to the matching standard format. The exported file validates against the standard’s published schema.

Consumers and external tools that support ODPS or ODCS can then ingest the product directly from that export, with no custom integration for Dawiso. A product you describe here is not locked into Dawiso: it can be published, moved, and validated wherever those standards are understood.