Skip to main content

Alignment with Existing Standards

The Base Product Specification (BPS) does not operate in isolation.
It is deliberately designed to align with and extend existing standards in metadata, provenance, and deployment.
This section describes the relationship between BPS and other specifications.

1. Alignment with DPDS and DPROD​

  • DPDS (Data Product Descriptor Specification):

    • BPS generalizes the deployment concept of DPDS into PDS.
    • DPDS-compliant descriptors are valid specializations of PDS.

  • DPROD (Data Product Ontology):

    • BPS generalizes the semantic concept of DPROD into PROD.
    • DPROD-conformant models can be mapped directly to PROD entities.

✅ Implication:
DPDS and DPROD are first-class extensions of BPS.

2. Alignment with AI Standards​

  • AIPDS and AIPROD:

    • These extend PDS/PROD for AI-specific concerns (inputs, outputs, risk classification, fairness metrics).
    • Align with [NIST AI RMF], [ISO/IEC 22989], and [ISO/IEC 42001].

  • Model Documentation (Model Cards, Datasheets):

    • These practices can be directly expressed within PROD descriptors (e.g., bps:evaluation, bps:metric).

✅ Implication:
BPS provides a home for AI product descriptors while remaining compatible with emerging governance frameworks.

3. Alignment with Metadata Standards​

  • Dublin Core (DC):

    • BPS uses Dublin Core terms for identifiers, titles, and descriptions (dct:title, dct:description).

  • DCAT (Data Catalog Vocabulary):

    • BPS aligns with DCAT concepts such as dcat:Dataset, dcat:Distribution.
    • A PDS can be seen as analogous to Distribution, while a PROD maps more closely to Dataset or Resource.

  • PROV-O (Provenance Ontology):

    • BPS reuses PROV-O for provenance relationships (wasGeneratedBy, wasDerivedFrom).

✅ Implication:
BPS descriptors are interoperable with Linked Data ecosystems and can be published into catalogs, graphs, and registries.

4. Alignment with Software/Deployment Standards​

  • OpenAPI / AsyncAPI:

    • PDS descriptors may include or reference OpenAPI/AsyncAPI definitions for service endpoints.
    • Ensures technical alignment with widely used API ecosystems.

  • Kubernetes Manifests / Helm Charts:

    • PDS descriptors for software products may reference these artifacts.

✅ Implication:
BPS does not replace existing deployment tools; it references them as artifacts within PDS.

5. Alignment with Governance and Risk Standards​

  • GDPR, HIPAA, PCI-DSS:

    • PROD descriptors can capture compliance obligations (bps:policy, bps:constraint).

  • EU AI Act:

    • AI-specific PROD descriptors can declare risk classification levels.

  • ISO/IEC Governance Standards:

    • BPS is compatible with organizational governance frameworks (e.g., ISO/IEC 38500, ISO/IEC 42001).

✅ Implication:
BPS descriptors support policy-awareness without embedding regulation-specific logic.

6. Alignment with external ecosystems​

  • Classification aligns with external taxonomy systems (e.g., UNSPSC/NAICS or internal IRIs).
  • Certification aligns with external compliance ecosystems (ISO/IEC, CE, PCI-DSS).
  • HealthIndicator aligns with observability tooling (SLIs/SLOs, Prometheus, OpenTelemetry) without prescribing a stack. ===TODO===

7. Summary of Alignment​

DomainStandard / PracticeAlignment in BPS
Data ProductsDPDS, DPRODPDS/PROD extensions
AI ProductsNIST AI RMF, ISO AI, Model CardsAIPDS/AIPROD
MetadataDublin Core, DCAT, PROV-OShared vocabulary
SoftwareOpenAPI, AsyncAPI, KubernetesPDS references
GovernanceGDPR, PCI-DSS, EU AI ActPROD obligations

8. Guiding Approach​

BPS is not a competitor to existing standards.
Instead, it acts as a meta-framework:

  • Providing a consistent split between PDS (deployment) and PROD (semantics).
  • Offering a lightweight, universal base onto which domain-specific profiles can be built.
  • Ensuring future alignment with standards bodies without breaking compatibility.