A Founder’s Guide to the DPROD Data Product Ontology: Standards for Decentralized Data

Updated October 2026

DPROD is the Data Products Ontology, an open specification for describing data products as linked metadata. It extends the W3C DCAT vocabulary with owners, domains, purpose, lifecycle, and input and output ports. The Object Management Group lists it as version 1.0 beta 2, published September 2026. Use it when you want data product metadata that machines and other teams can read without translation.

What problem does DPROD solve?

DPROD gives every team the same way to say what a data product is, who owns it, and how to reach it. Without that, each domain describes its products in a different wiki template or catalog field. Discovery, lineage, and access review then depend on people reading prose.

The idea comes from data mesh. Zhamak Dehghani's 2019 data mesh article argued that domain teams should own their data and serve it as products. She also called for federated governance with global standards so those products still work together. DPROD is one answer to the standards half of that argument.

The cost of skipping a shared model shows up later. A finance team calls something a product, a marketing team calls it a dataset, and the catalog calls it an asset. Nobody can query across all three. For a plain language primer on the concept itself, see our guide to what a data product is.

What is the status of DPROD in 2026?

DPROD is on the OMG standards track but not final. OMG opened a public request for comments on September 24, 2024, with comments due in November that year. The spec page now lists 1.0 beta 2 with an adoption date of September 2026, released for informational purposes.

The beta 2 release page lists two normative machine readable files. One is an OWL ontology and the other is a SHACL shapes file. A set of mostly JSON-LD example data products ships alongside them as informative material.

The ontology began outside OMG. The EKGF GitHub repository says it was originally created by the EKGF Data Product Workgroup. That repo still hosts the readable spec and its examples.

One correction to older write-ups, including an earlier version of this article. DPROD is not a W3C standard. It is an OMG specification built on W3C vocabularies such as DCAT 3, a W3C Recommendation since August 22, 2024.

How is a DPROD data product structured?

A DPROD data product is a DCAT resource with a small set of extra properties. The ontology file defines DataProduct as a subclass of dcat:Resource. Everything else reuses DCAT classes for datasets, distributions, and data services.

How do ports, distributions, and datasets connect?

The DPROD specification treats every port as a DCAT data service. Input ports receive data by push, through a subscription, or by pull, through a query. Output ports share what the product generates.

A port links to a distribution with isAccessServiceOf. A distribution links to its dataset with isDistributionOf. Datasets then point to a logical model or standard with dct:conformsTo. Those three hops are what make product level lineage queryable.

What lifecycle values does DPROD use?

Lifecycle status comes from a controlled list based on the EDM Council CDMC model. The spec gives Ideation, Design, Build, Deploy, and Consume as examples. A shared list matters because it lets a catalog filter out products that are still being designed.

What does a minimal descriptor look like?

A minimal descriptor names the product, its owner, its purpose, its lifecycle, and one output port. The example below is illustrative Turtle, not copied from the spec.

@prefix dprod: <https://ekgf.github.io/dprod/> .
@prefix dcat:  <http://www.w3.org/ns/dcat#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ex:    <https://data.example.com/> .

ex:customer-churn a dprod:DataProduct ;
  rdfs:label "Customer churn scores" ;
  dprod:dataProductOwner ex:team-retention ;
  dprod:domain ex:domain-customer ;
  dprod:purpose "Weekly churn risk per active account" ;
  dprod:lifecycleStatus ex:status-consume ;
  dprod:outputPort ex:churn-api ;
  dprod:outputDataset ex:churn-scores .

ex:churn-api a dcat:DataService ;
  dcat:endpointURL <https://api.example.com/churn> .

@prefix dprod: <https://ekgf.github.io/dprod/> .
@prefix dcat:  <http://www.w3.org/ns/dcat#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ex:    <https://data.example.com/> .

ex:customer-churn a dprod:DataProduct ;
  rdfs:label "Customer churn scores" ;
  dprod:dataProductOwner ex:team-retention ;
  dprod:domain ex:domain-customer ;
  dprod:purpose "Weekly churn risk per active account" ;
  dprod:lifecycleStatus ex:status-consume ;
  dprod:outputPort ex:churn-api ;
  dprod:outputDataset ex:churn-scores .

ex:churn-api a dcat:DataService ;
  dcat:endpointURL <https://api.example.com/churn> .

@prefix dprod: <https://ekgf.github.io/dprod/> .
@prefix dcat:  <http://www.w3.org/ns/dcat#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ex:    <https://data.example.com/> .

ex:customer-churn a dprod:DataProduct ;
  rdfs:label "Customer churn scores" ;
  dprod:dataProductOwner ex:team-retention ;
  dprod:domain ex:domain-customer ;
  dprod:purpose "Weekly churn risk per active account" ;
  dprod:lifecycleStatus ex:status-consume ;
  dprod:outputPort ex:churn-api ;
  dprod:outputDataset ex:churn-scores .

ex:churn-api a dcat:DataService ;
  dcat:endpointURL <https://api.example.com/churn> .

Check the namespace and the lifecycle term IRIs against the beta 2 files before you publish. Those are exactly the details most likely to shift before 1.0.

How do policies, quality, and observability fit in?

DPROD describes governance facts but does not enforce them. Policies use the W3C ODRL information model, a Recommendation since February 2018, through the hasPolicy property. Datasets can carry an information sensitivity classification defined in the ontology file.

The spec examples also show data quality measurements attached to a product and observability ports that emit log entries. Teams can query those ports with SPARQL. Treat these as patterns to copy rather than a full quality framework.

Enforcement still belongs to your platform. A warehouse role, a catalog access workflow, or an agent gateway has to read the policy and apply it. For how provenance and audit trails complete that picture, see our piece on provenance, lineage, and auditability.

How does DPROD compare with ODPS, Bitol, and catalog data products?

DPROD is the RDF option among several data product standards. The others are document formats or vendor features, and each fits a different job.

The Open Data Product Specification reached version 4.1 on October 24, 2025. It covers pricing, service levels, data quality, access, licensing, and strategy, with YAML as the source of truth. That makes it a strong fit for marketplaces, but it does not model relationships as a graph.

Bitol publishes the Open Data Contract Standard, now at v3.2.0, and its own Open Data Product Standard. Both are Apache 2.0 under the Linux Foundation AI and Data umbrella. ODCS is the most common way to write a machine readable data contract, so it pairs well with DPROD rather than competing with it.

Catalogs also ship their own data product objects. In Microsoft Purview Unified Catalog, a data product groups assets under a use case with owners and an access policy. That works well inside Purview, but the page does not mention a DCAT or DPROD export.

Why does DPROD matter for AI and knowledge graphs?

Agents and AI tools need context they can query, not prose they have to guess at. A DPROD graph tells a tool who owns a dataset, what it is for, how sensitive it is, and which policy applies. That turns discovery and access checks into queries.

DPROD also gives an enterprise ontology a natural place to attach data. Your business concepts describe customers, contracts, and products. DPROD describes the data products that hold facts about them. Linking the two with conformsTo connects meaning to the actual tables and APIs. Our explainer on how an enterprise ontology works as a semantic backbone covers the business model side, and how ontology powers AI analytics shows the payoff.

There is an ownership point here too. Descriptions of what your data means and who answers for it are institutional knowledge. Keeping them in an open format such as DPROD, on infrastructure you control, means they survive a catalog migration.

Galaxy works with teams to build this kind of semantic foundation on the stack they already run, using internal tooling it plans to open source, and builds in the open with Filament.

How should a team adopt DPROD?

Start small and keep descriptors next to the code that builds each product. These steps work for a first pilot.

1. Pick three to five products that other teams already consume.

2. Write one JSON-LD descriptor per product with owner, domain, purpose, lifecycle, and output ports.

3. Validate every descriptor in CI against the beta 2 SHACL shapes file.

4. Link each output dataset to its schema or data contract with conformsTo.

5. Load the descriptors into any SPARQL capable store and test lineage and ownership queries.

6. Map your catalog's product fields to DPROD so the two stay in sync.

Keep company specific terms in your own namespace. That way a change in the DPROD beta only touches the shared terms. If you are deciding where product metadata should live relative to your catalog and semantic layer, our comparison of catalogs, metadata layers, and semantic layers can help.

Frequently asked questions

What is DPROD?

DPROD, the Data Products Ontology, is an Object Management Group specification for describing data products in RDF. It extends the W3C DCAT vocabulary with a DataProduct class and properties for owner, domain, purpose, lifecycle status, input and output ports, and datasets. It was first built by the EKGF Data Product Workgroup and is now on the OMG standards track.

Is DPROD a W3C standard?

No. DPROD is an OMG specification, not a W3C one. It builds on W3C standards such as DCAT 3, ODRL, PROV, and SHACL, which is why it is sometimes described loosely as W3C based. The OMG page lists version 1.0 beta 2, dated September 2026, with beta status. A formal 1.0 release had not been published as of October 2026.

Is DPROD ready for production use?

It is usable but not final. Beta 2 ships a normative OWL ontology file and a SHACL shapes file, so teams can model and validate data products today. Expect some terms to change before the formal release. Pin the version you adopt, keep your own extensions in a separate namespace, and plan a small migration when 1.0 lands.

How is DPROD different from DCAT?

DCAT describes catalogs, datasets, distributions, and data services. It has no concept of a data product with an owner, a business purpose, a lifecycle, and declared input and output ports. DPROD adds exactly that layer. Its DataProduct class is a subclass of the DCAT Resource class, so any DCAT aware tool can still read the datasets and services underneath.

How does DPROD compare with the Open Data Product Specification?

ODPS is a YAML and JSON standard from the Linux Foundation, at version 4.1 since October 2025. It covers commercial details such as pricing, service levels, and licensing. DPROD is an RDF ontology focused on semantics, lineage, and policy links. ODPS suits marketplaces and product listings. DPROD suits knowledge graphs. Some teams publish both from one source.

Do I need a knowledge graph to use DPROD?

No. The examples are mostly JSON-LD, which is ordinary JSON with a context file, so you can keep descriptors in Git and validate them in CI. A graph store becomes useful once you have dozens of products and want to query lineage or ownership across them. Any RDF store that runs SPARQL can hold DPROD descriptors.

What does a DPROD port represent?

A port is a DCAT DataService attached to a data product. Input ports take data in, either pushed by a subscription or pulled by a query. Output ports share what the product produces. Each port links to a distribution, which links to a dataset. Walking those links from one product to another gives you product level lineage.

Where do policies and access rules go in DPROD?

DPROD uses the W3C ODRL policy language through the hasPolicy property. A policy can state permissions, prohibitions, and constraints, such as who may use a dataset and for what purpose. Datasets can also carry an information sensitivity classification. These are descriptions, not enforcement, so your platform still has to apply them at query time.

How does DPROD relate to data contracts?

They solve different problems and fit together. A data contract, such as one written in Bitol ODCS, fixes the schema, quality rules, and service levels between a producer and a consumer. DPROD describes the product, its owner, purpose, ports, and lineage. One clean pattern points a DPROD dataset at its contract with the conformsTo property.

Why does DPROD matter for AI agents?

Agents need to find the right data, know who owns it, and know whether they may use it. DPROD puts those facts in a machine readable graph instead of a wiki page. An agent or tool can query owner, purpose, sensitivity, and policy before it touches a dataset. That makes discovery and access checks repeatable rather than guessed.