OPEN DATA PRODUCT VOCABULARY - The Linux Foundation

Version DEVELOPMENT

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 (RFC 2119 and RFC 8174) when, and only when, they appear in all capitals, as shown here.

The vocabulary is shared under Apache 2.0 license. Development of the vocabulary is under the umbrella of the Linux Foundation.

Introduction

The Open Data Product Vocabulary, ODPV, is a vendor-neutral, open-source, machine-readable controlled vocabulary for data product management. ODPV defines shared terms used across the OpenDataProducts.org standards family, including data products, catalogs, graphs, value concepts, governance concepts, and relationship terms. It is designed to help organizations use consistent language across specifications, catalogs, graph implementations, AI assistants, and GraphRAG-ready data product portfolios.

What ODPV Defines

ODPV defines the shared vocabulary layer for the OpenDataProducts.org standards family. The current vocabulary contains 78 terms across four concept groups:

ODPV Core: ODPV Core defines foundational terms used across the standards family. These terms describe the basic objects, roles, classifications, and references needed to manage data products, catalogs, graphs, and agent workflows.

ODPV Value: ODPV Value defines terms that connect data products to business demand, objectives, strategy, outcomes, and prioritization. These terms help connect data products to measurable value and portfolio-level decision-making.

ODPV Governance: ODPV Governance defines terms for quality, access, licensing, pricing, support, legal, operational, and compliance context. These terms help describe how data products are governed, accessed, controlled, and trusted.

ODPV Relationships: ODPV Relationships defines reusable relationship terms for graph implementation, portfolio analysis, and cross-spec linking. These relationship terms help connect data products, use cases, objectives, KPIs, signals, providers, consumers, policies, catalogs, workflows, agents, and services in a consistent way.

These groups create a common language for describing, connecting, validating, and reasoning over data product portfolios.

Suggest addition to the vocabulary

Machine-Readable Vocabulary Resources

ODPV is published in multiple machine-readable forms for tools, AI agents, catalogs, graph workflows, and semantic tooling.

Agent Helper Commands

ODPV includes source helper scripts for repeatable local vocabulary lookup, relationship checking, and context engineering workflows.

Companion Vocabulary, Not a Heavy Ontology

ODPV is not intended to be a heavy ontology. It is a practical controlled vocabulary that gives stable reference terms to the OpenDataProducts.org standards family. Each specification can reference ODPV terms instead of redefining shared concepts locally. Shared terms belong in ODPV. Spec-specific terms stay in the relevant specification. Extensions can define additional domain-specific or organization-specific terms.

Relationship to ODPS, ODPC, and ODPG

• ODPS defines one data product.
• ODPC defines reusable catalog and portfolio objects.
• ODPG defines relationships between data products, use cases, objectives, KPIs, signals, and other portfolio objects.
• ODPV defines the shared language used by all of them.

Used together, ODPS, ODPC, ODPG, and ODPV create a machine-readable operating model for data product management.

Why ODPV Matters

ODPV helps prevent terminology drift across the standards family. Without a shared vocabulary, each specification may define terms such as Data Product, Use Case, Objective, KPI, Signal, Owner, SLA, License, or Relationship slightly differently. ODPV gives these terms one stable reference point. This improves:

• Specification alignment
• Graph implementation
• Metadata validation
• Catalog interoperability
• AI-assisted discovery
• GraphRAG context
• Portfolio analysis
• Tool development

Automated Drift Detection

ODPV includes automated cross-spec drift detection for the Open Data Product standards family. A weekly GitHub Action fetches the published ODPS, ODPC, and ODPG schemas, compares their schema terms against the canonical ODPV vocabulary, and writes a dated report.

Reports are kept in cross-spec-drift/ so the project can track how alignment changes over time and use the historical reports as input for later analysis.

Example Use

• A data product in ODPS can reference ODPV terms for concepts such as DataProduct, ProductDetails, ProductStrategy, DataHolder, SLA, DataQuality, License, DataAccess, PricingPlan, PaymentGateway, and Support.
• A catalog in ODPC can reference ODPV terms for concepts such as DataProductCatalog, UseCase, BusinessObjective, KPI, Signal, Gap, Priority, Reference, and Owner.
• A graph in ODPG can reference ODPV terms for node types and relationship types such as Agent, Workflow, Capability, uses, supports, contributesTo, measures, dependsOn, produces, consumes, ownedBy, alignsWith, impacts, exposes, and identifies.

Specification Aims

• Define shared terms for data product management.
• Reduce duplicate term definitions across ODPS, ODPC, and ODPG.
• Prevent terminology drift across the standards family.
• Support consistent graph node and relationship naming.
• Support AI-assisted discovery, metadata generation, and GraphRAG.
• Improve interoperability between catalogs, platforms, marketplaces, and tools.
• Provide a lightweight path toward semantic knowledge graph implementation.
• Keep formal ontology work optional.

Vocabulary Toolkit

Snippet of YAML version:

id: DataProduct
uri: https://opendataproducts.org/odpv-v1.0/terms/DataProduct
type: object
status: stable
preferredLabel:
  en: Data Product
definition:
  en: A managed data offering designed for reuse, with 
      defined ownership, access, quality, usage terms, 
      and value context.
alsoKnownAs:
  en:
    - data product
    - data offering
    - reusable data asset
relatedTerms:
  - Dataset
  - DataService
  - Distribution
usedIn:
  - ODPS
  - ODPC
  - ODPG

ODPV is published in several forms for different users and tools. This specification provides the human-readable documentation, while the vocabulary files provide machine-readable representations for validation, catalog integration, graph construction, AI retrieval, linked-data tooling, and automation. Use odpv.yaml as the canonical source, odpv.json when JSON is easier to consume, odpv.jsonld or odpv.skos.ttl for semantic web and linked-data tooling, the section YAML files when only one vocabulary area is needed, and terms.jsonl for search, embeddings, and lightweight AI agent workflows.

The primary implementation toolkit for the whole Open Data Product standards family is the Open Data Product Agent SDK. Use it when building tools, validators, agent workflows, catalog integrations, graph workflows, or automation that needs to work across ODPS, ODPC, ODPG, and ODPV together.

Agent-oriented helper scripts are available in the source repository for maintaining and using the vocabulary files.

The Markdown tables in this specification are intended for human readers. The YAML files are intended for programmable use, automation, validation, AI retrieval, and graph-based tooling.

AI Agent Usage Patterns

ODPV is designed to be usable by AI agents, catalog tools, retrieval systems, graph systems, and automation workflows. From an agent perspective, ODPV provides the shared terminology layer for data product management: it names stable concepts, labels, definitions, aliases, related terms, and relationship names that other specifications and tools can reference consistently.

ODPS defines one data product. ODPC defines reusable catalog and portfolio objects around data products. ODPG defines relationships between those objects. ODPV provides the shared vocabulary terms used across the standards family. This separation helps agents choose the right source before acting.

Agent capabilities enabled by ODPV

Agents can use ODPV to:

• select stable term ids and uris for data product management concepts
• map user language, synonyms, and internal terminology to preferred ODPV terms
• retrieve definitions, labels, aliases, related terms, and examples from terms.jsonl
• validate vocabulary files against odpv.schema.json
• explain distinctions between nearby terms such as DataProduct, Dataset, DataService, and Distribution
• choose relationship terms such as uses, supports, requires, contributesTo, measures, dependsOn, produces, consumes, governedBy, providedBy, consumedBy, ownedBy, alignsWith, impacts, exposes, and identifies
• prepare graph-ready relationship names for ODPG or another graph implementation
• support catalog alignment by using the same terms in ODPC catalogs and ODPS product descriptions
• detect terminology drift, duplicate concepts, unclear aliases, or missing shared terms
• suggest extension terms when an organization-specific or domain-specific concept is not part of the official vocabulary

Common agent workflows

Agent behavior constraints

Agents using ODPV should keep vocabulary boundaries clear:

• Do not treat ODPV as a replacement for ODPS, ODPC, or ODPG.
• Do not put full product metadata, catalog objects, or graph structures into ODPV terms.
• Do not redefine official ODPV term ids, uris, labels, or meanings locally.
• Do not invent new official terms when an existing ODPV term fits.
• Do not use relatedTo when a more specific relationship term such as supports, requires, dependsOn, or governedBy applies.
• Do not assume aliases are preferred labels; use them for search, mapping, and onboarding.
• Do not promote ODPG-local aliases such as API or monitors into standalone ODPV ids when DataService and measures are the canonical vocabulary terms.
• Do not edit generated vocabulary artifacts directly when changing official vocabulary content; update source/vocab/odpv.yaml first and regenerate derived files.

Example prompts ODPV enables

Find the best ODPV term for "data API" and return the stable id and uri.

Map these internal catalog labels to ODPV preferred terms and explain uncertain matches.

Choose ODPV relationship terms for these graph edges and avoid generic relationships where possible.

Validate this ODPV vocabulary file and suggest schema-compliant repairs.

Identify terminology drift between this ODPC catalog and the official ODPV terms.

Propose an ODPV extension term for a missing domain-specific concept.

Term Governance Rules

ODPV is a shared vocabulary, not a catch-all list of every field used by every specification. New terms should be added when they improve shared understanding across the Open Data Products standards family or when they provide a stable bridge between specifications, tools, catalogs, graphs, and AI agents.

Use these rules when reviewing drift reports, GitHub issues, pull requests, or proposed vocabulary additions.

Adding A New Official Term

A new ODPV term should include:

• stable id and uri
• type
• status
• introducedIn
• preferredLabel
• clear definition
• useful alsoKnownAs aliases
• relatedTerms
• usedIn
• examples
• external mappings when an established vocabulary applies

Definitions should describe what the concept means, not where it appears in a schema. Examples should show practical use in ODPS, ODPC, ODPG, tools, catalogs, graphs, or AI workflows.

Adding An Alias

Add an alias when the proposed term is safely equivalent to an existing ODPV term. Alias examples include:

• casing differences such as license for License
• plural schema names such as pricingPlans for PricingPlan
• source-spec naming differences such as API for DataService
• relationship wording differences such as monitors for measures

Do not add an alias when the source term would change the meaning of the canonical term. In that case, add a new term, add a mapping, use an extension, or open a source-spec issue.

Adding External Mappings

Use external mappings to connect ODPV terms to established vocabularies such as DCAT, SKOS, PROV-O, ODRL, Dublin Core, schema.org, or SPDX.

Mapping strength matters:

When in doubt, prefer closeMatch over exactMatch.

Drift Review Workflow

When a drift report shows Possible drift:

1. Check whether the source term already maps to an ODPV term through alsoKnownAs.
2. Decide whether the source term is a shared concept, alias, source-spec detail, extension candidate, or source-spec issue.
3. If adding or changing ODPV, update source/vocab/odpv.yaml first.
4. Regenerate artifacts with scripts/generate_vocab_artifacts.py.
5. Validate with scripts/validate_vocab.py.
6. Refresh the drift report with scripts/check_cross_spec_drift.py.

The goal is not to force every source term into ODPV. The goal is to keep shared vocabulary stable, useful, and interoperable.

ODPV Core

ODPV Core defines the foundational terms used across the Open Data Products specification family. These terms describe the main objects, roles, classifications, and references that appear in ODPS, ODPC, and ODPG.

The purpose of the core vocabulary is to create a shared language for describing data products and their surrounding ecosystem. It helps different specifications, catalogs, graphs, tools, and platforms use the same concepts consistently.

Each term has one canonical ODPV name. Alternative terms are included to support search, mapping, onboarding, and AI-assisted interpretation. Related terms show nearby concepts that are connected to the term but have a different meaning.

The core terms are intentionally lightweight. They do not replace the full object models of ODPS, ODPC, or ODPG. Instead, they provide a common vocabulary layer that supports interoperability across the Open Data Products ecosystem.

Snippet of YAML version:

id: DataProduct
uri: https://opendataproducts.org/odpv-v1.0/terms/DataProduct
type: object
status: stable
introducedIn: 1.0.0
preferredLabel:
  en: Data Product
definition:
  en: A managed data offering designed for reuse, with defined 
      ownership, access, quality, usage terms, and value context.
alsoKnownAs:
  en:
    - data product
    - data offering
    - reusable data asset
relatedTerms:
  - Dataset
  - DataService
  - Distribution
usedIn:
  - ODPS
  - ODPC
  - ODPG

Suggest addition to the vocabulary

ODPV Value

ODPV Value defines the terms used to describe why data products matter, where they create value, and how that value connects to business outcomes.

These terms help connect data products to use cases, objectives, KPIs, signals, gaps, opportunities, risks, and benefits. They make the vocabulary useful beyond technical metadata by linking data products to planning, prioritization, investment, and measurable impact.

The value vocabulary supports portfolio-level thinking. It helps teams describe which data products are needed, which use cases they support, what outcomes they contribute to, and where new opportunities or gaps exist.

Each term has one canonical ODPV name. Also known as terms help users map familiar business language to the official vocabulary. Related terms show nearby concepts that are connected but should not be treated as identical.

Snippet of YAML version:

id: BusinessObjective
uri: https://opendataproducts.org/odpv-v1.0/terms/BusinessObjective
type: object
status: stable
introducedIn: 1.0.0
preferredLabel:
  en: Business Objective
definition:
  en: A business goal or intended outcome that data products, 
      use cases, or portfolio actions support.
alsoKnownAs:
  en:
    - objective
    - business goal
    - strategic goal
    - target outcome
relatedTerms:
  - Outcome
  - KPI
  - Impact
  - UseCase
usedIn:
  - ODPC
  - ODPG

Suggest addition to the vocabulary

ODPV Governance

ODPV Governance defines the terms used to describe how data products are controlled, protected, accessed, licensed, and operated.

These terms help connect data products to quality expectations, service commitments, access rules, usage rights, policies, compliance requirements, and responsibility models. They make governance visible as part of the product vocabulary instead of treating it as separate documentation.

The governance vocabulary supports trusted reuse. It helps teams describe who is accountable, what rules apply, how access works, what consumers are allowed to do, and what obligations must be followed.

Each term has one canonical ODPV name. Also known as terms help users map familiar governance, legal, operational, and technical language to the official vocabulary. Related terms show nearby concepts that are connected but should not be treated as identical.

Snippet of YAML version:

id: DataQuality
uri: https://opendataproducts.org/odpv-v1.0/terms/DataQuality
type: object
status: stable
introducedIn: 1.0.0
preferredLabel:
  en: Data Quality
definition:
  en: The expected, measured, or reported quality of a data product, 
      dataset, distribution, or data service.
alsoKnownAs:
  en:
    - quality
    - data quality score
    - quality assessment
    - quality metrics
relatedTerms:
  - SLA
  - DataContract
  - Stewardship
  - ComplianceRule
usedIn:
  - ODPS
  - ODPC
  - ODPG

Suggest addition to the vocabulary

ODPV Relationships

ODPV defines the names and meanings of relationship types. ODPG defines how those relationship types are used in graph structures. In other words, ODPV defines the vocabulary. ODPG defines the graph model.

ODPV Relationships defines the terms used to connect data products, catalogs, use cases, objectives, KPIs, signals, governance objects, and related portfolio items.

These terms describe how objects support, require, measure, govern, depend on, replace, or relate to each other. They turn separate vocabulary terms into a connected model that AI tools, catalogs, graph systems, and portfolio applications can understand.

The relationship vocabulary is especially important for ODPG. It provides the shared relationship types needed to build data product graphs, trace value paths, identify gaps, and connect data products to business outcomes.

Each relationship term has one canonical ODPV name. Also known as terms help users map familiar relationship language to the official vocabulary. Related terms show nearby relationship types that are connected but should not be treated as identical.

Snippet of YAML version:

id: supports
uri: https://opendataproducts.org/odpv-v1.0/terms/supports
type: relationship
status: stable
introducedIn: 1.0.0
preferredLabel:
  en: supports
definition:
  en: Indicates that one object helps enable, serve, or 
      make another object possible, such as a data product 
      supporting a use case.
alsoKnownAs:
  en:
    - enables
    - serves
    - helps
    - provides support for
relatedTerms:
  - contributesTo
  - requires
  - relatedTo
usedIn:
  - ODPG

Suggest addition to the vocabulary

Extensions

ODPV defines a shared controlled vocabulary for the OpenDataProducts.org standards family. It provides stable terms, labels, definitions, concept groups, mappings, and relationship names used across ODPS, ODPC, and ODPG. Organizations may need additional terms for domain-specific, platform-specific, or organization-specific use cases. These terms can be added through vocabulary extensions.

Extensions should add new terms, labels, mappings, concept groups, related terms, or usage notes. They should not change the meaning of official ODPV terms. Extension terms should use a separate namespace or prefix to avoid conflict with official ODPV terms.

Examples:

• x-mobility:CongestionIndex
• x-healthcare:PatientCohort
• x-finance:RiskExposure
• x-platform:InternalDataOwner

Extension terms may define:

• id
• preferredLabel
• alternativeLabels
• definition
• conceptGroup
• relatedTerms
• externalMappings
• notes

Snippet of YAML version:

id: x-mobility:CongestionIndex
preferredLabel:
  en: Congestion Index
definition:
  en: A domain-specific indicator describing the level 
      of traffic congestion for a mobility data product.
conceptGroup: x-mobility
relatedTerms:
  - KPI
  - Signal
externalMappings:
  - scheme: example-mobility-taxonomy
    value: congestion-index
notes:
  en: Extension terms use a separate namespace so they 
      do not conflict with official ODPV terms.

Extensions are not part of the official ODPV vocabulary unless they are later adopted into the specification. Tooling may ignore extension terms unless explicit support has been added. Extensions should not be used to redefine official ODPV terms such as DataProduct, UseCase, BusinessObjective, KPI, Signal, DataQuality, License, or supports.

Useful and widely adopted extensions may become candidates for future versions of ODPV. To propose useful extensions, raise an issue in GitHub:

Open Data Products Vocabulary GitHub issues

Editors and contributors

This specification is openly developed and a lot of the work comes from community. We list all community contributors as a sign of appreciation. Maintainers process the feedback and draft new candidate releases, which may become the versions of the specification.

Maintainers:

• Jarkko Moilanen