Part A · The Source Data Product
Exercise 3 · Describe Your Data Product
Describe the data product behind the contracts with ODPS.
~20 min0 of 4 steps done
Your data contracts describe the interface of your data: tables, types, quality rules. Consumers want more: What is this data for? Who owns it? Which versions exist, and which one should I use? That is the job of the data product, described with the Open Data Product Standard (ODPS).
You will learn
- Understand the difference between a data product and a data contract
- Describe the Orders data product with ODPS 1.1, including its type and output ports
- Validate the description with the Data Product CLI
Create the data product
Create the file
The Data Product CLI creates a starter file:
dataproduct init orders.odps.yaml📄 data product written to orders.odps.yamlOpen orders.odps.yaml in your IDE. It contains placeholders and commented-out sections.
Replace the top part with the fundamentals of your Orders product:
YAML
apiVersion: v1.1.0
kind: DataProduct
id: orders
name: Orders
version: 1.0.0 # the version of the data product, independent of the contract versions
status: active
type: sourceAligned
domain: ecommerce
description:
purpose: # what is this data product for?
limitations: # what should consumers know before using it?Replace the purpose and limitations comments with real text: what does a consumer need to know before requesting access?
Add the output ports
Add one output port per data contract. The contractId must match the contract's id:
YAML
outputPorts:
- name: orders_v1
description: Orders and line items tables in PostgreSQL (v1, superseded by v2)
deprecated: true
version: 1.0.0
contractId: orders_v1
- name: orders_v2
description: # ...
version: 2.0.0
contractId: orders_v2Write the description for orders_v2 yourself. Remove the example output port from dataproduct init.
deprecated: true (new in ODPS 1.1) marks the orders_v1 port as no longer recommended. It stays documented for existing consumers, while new consumers pick orders_v2.
Add team and support
Add team and support. Reuse what you defined in your contracts:
YAML
team:
name: order_data_team
members:
- username: [email protected]
role: Owner
support:
- channel: "#order-data-help"
url: https://example.slack.com/archives/order-data-help
tool: slackValidate
Lint the data product
Validate against the official ODPS JSON schema:
dataproduct lint orders.odps.yaml✅ Data product is valid against ODPS v1.1.0
🟢 Data product is valid.Make it fail once: change kind: DataProduct to kind: DataProdukt and lint again:
dataproduct lint orders.odps.yaml❌ Check that data product is valid against ODPS v1.1.0: kind: 'DataProdukt' is not one of
['DataProduct']
🔴 Data product is invalid.The CLI names the wrong field and exits with code 1. Revert afterwards.
Quick check
Your Orders product releases orders_v3 next year. What changes in orders.odps.yaml?
Bonus
orders_v1isretired. Should its deprecated output port stay in the product description, or be removed? Weigh transparency for existing consumers against a clean catalog.- ODPS 1.1 also supports a
contextblock for AI agents at product and output port level, like ODCS 3.2. Addinstructionsthat tell an agent which port to use. - Add
tagsto the data product, e.g.['orders', 'ecommerce'], and lint again.