Skip to main content

Base Product Meta-Model

1. Purpose​

The Base Product Meta-Model (BPMM) provides the conceptual framework underpinning the Base Product Specification (BPS).
It defines the core entities, relationships, and lifecycle states that apply to all products, regardless of domain.
Domain-specific product specifications (e.g., DPDS/DPROD for Data Products, APDS/APROD for AI Products) extend this model with additional semantics.

2. Core Entities​

The following abstract entities constitute the kernel of the BPMM:

  1. Product

    • The central abstraction representing a unit of value offered for consumption.
    • Has: identifier, title, description, category.

  2. Product Version

    • Immutable snapshot of a Product at a given release.
    • Attributes: versionId, releaseDate, status (Draft, Published, Deprecated, Retired).

  3. Ownership and Accountability

    • Represented by Agent, which denotes any bearer of accountability for a Product.
    • Subtypes include:
      • Human: An individual person.
      • Collective: A group, team, department, or organization.
      • Non-Human: An autonomous digital entity, such as an AI agent, smart contract, or decentralized autonomous organization (DAO).
      • Hybrid: A human augmented by AI or other cognitive/physical enhancements (trans-human or AI-assisted roles).
    • Properties: owner, publisher, responsibleParty, with explicit annotation of agentType to distinguish human, collective, non-human, or hybrid responsibility.

  4. Interface

    • Defines how a Product is consumed or interacts with other systems.
    • Subtypes:
      • InputPort (data, signals, parameters consumed).
      • OutputPort (data, predictions, services provided).
      • ServiceEndpoint (APIs or callable services).

  5. Contract

    • Captures obligations, guarantees, or promises (e.g., SLA, SLO, fairness).
    • Properties: hasMetric, hasObligation, hasConstraint.

  6. Asset

    • Represents artifacts used by or exposed from a Product.
    • Examples: dataset, model file, API specification, physical component.

  7. Provenance

    • Relationship to source assets, processes, or activities.
    • Aligned with PROV-O (prov:wasDerivedFrom, prov:wasGeneratedBy).

  8. Evaluation

    • Assessment of a Product Version against criteria.
    • Properties: evaluationDate, evaluatedBy, metricResults.

  9. Metric

    • Quantitative or qualitative measure (e.g., accuracy, latency, freshness, defect rate).

  10. Policy and Risk Profile

    • Governance-related descriptors.
    • Attributes: riskClassification, regulatoryContext, policyAttachment.

  11. Purpose / IntendedUse

    • Concise statement of the product’s intended function or application.
    • Distinct from general description; used for discovery and policy gating.

  12. Classification

    • Structured category reference with scheme, code, and label.
    • Examples: UNSPSC, NAICS, internal taxonomy IRIs.

  13. Certification

    • Evidence of compliance or conformance issued by an external body.
    • Attributes: certBody, certName, certId, validFrom, validTo, evidenceUri.

  14. HealthIndicator

    • Operational status/observability signals for a Product Version.
    • Examples: uptime %, MTBF, freshness, drift, lastCheckTime.

3. External Specification Alignment​

3.1 ExternalSpec Entity​

The ExternalSpec entity represents the linkage of a Product or Product Version to an external descriptor specification.
This allows the Base Product Specification (BPS) to remain lightweight, while enabling interoperability with domain-specific standards.

  • Attributes:

    • specUri — URI or IRI referencing the external specification.
    • name — Human-readable name of the external specification.
    • version — Version identifier of the specification.

  • Examples:

    • A Data Product Version may reference DPDS v1.0 or DPROD ontology v0.9.
    • An AI Product Version may reference an APDS draft or a Model Card schema.
    • A Software Product Version may reference an OpenAPI specification.

This design ensures that BPS does not duplicate existing standards, but instead provides a neutral anchoring point.

3.2 The dct:conformsTo Predicate​

The relationship between a ProductVersion and an ExternalSpec is expressed using the Dublin Core dct:conformsTo property:

  • Definition (Dublin Core):
    "dct:conformsTo indicates an established standard to which the described resource conforms."

  • Usage in BPS:

    • ProductVersion dct:conformsTo ExternalSpec
    • Example: This ProductVersion conforms to DPDS v1.0.

This ensures semantic alignment with widely adopted metadata vocabularies such as Dublin Core (DCTerms), making the BPS interoperable with digital library and metadata ecosystems.

3.3 Rationale for Including ExternalSpec​

The inclusion of ExternalSpec and dct:conformsTo provides three benefits:

  1. Interoperability — Products can declare conformance to domain-specific standards without BPS needing to replicate their details.
  2. Flexibility — New standards (e.g., APDS for AI Products) can be integrated seamlessly by referencing them as external specs.
  3. Sustainability — As standards evolve, Product Versions can update their conformance references without changing the BPS core.

In summary:
The ExternalSpec entity and the dct:conformsTo predicate ensure that the BPS serves as a neutral foundation, while remaining standards-aware and interoperable. They allow BPS to anchor itself in a broader ecosystem of specifications, avoiding duplication and promoting extensibility.

4. Relationships​

  • Product hasVersion → Product Version

  • Product Version hasInterface → Interface

  • Interface consumes → Asset (via InputPort)

  • Interface produces → Asset (via OutputPort)

  • ServiceEndpoint exposes → Asset (optional, for API specs or docs)

  • Product Version usesAsset → Asset

  • Product Version governedBy → Contract

  • Product Version governedBy → PolicyRiskProfile

  • Product Version evaluatedBy → Evaluation

  • Evaluation hasMetric → Metric

  • Product Version ownedBy → Agent (primary accountability)

  • Product Version publishedBy → Agent (optional)

  • Product Version maintainedBy → Agent (optional)

  • Product Version wasDerivedFrom → Provenance (aligned with PROV-O)

  • Product Version replaces / replacedBy → Product Version (version succession)

  • Product Version conformsTo → ExternalSpec

    • Implemented via Dublin Core dct:conformsTo
    • Examples: DPDS, DPROD, APDS, OpenAPI, Model Card schema

  • Product hasPurpose → Purpose / IntendedUse

  • Product hasClassification → Classification (0..*)

  • Product Version hasCertification → Certification (0..*)

  • Product Version hasHealth → HealthIndicator (0..*)

5. Lifecycle States​

A Product Version progresses through lifecycle states:

  • Draft → Initial state under creation.
  • Published → Available for consumption.
  • Deprecated → Superseded but still available for backward compatibility.
  • Retired → Withdrawn and no longer consumable.

Lifecycle management ensures traceability and accountability.

6. Alignment with External Standards​

The BPMM is aligned with existing standards to maximize interoperability:

  • W3C DCAT → for datasets and distributions.
  • W3C PROV-O → for provenance and lineage.
  • GoodRelations → for commercial product offers.
  • ISO/IEC AI Standards (22989, 42001) → for risk and accountability in AI.
  • DPDS/DPROD → for Data Product extensions.
  • APDS/APROD → for AI Product extensions.

7. Visual Conceptual Model - low view​

8. Visual Conceptual Model - basic view​

9. Visual Conceptual Model - intermediate view​

10. Essence of the Meta-Model​

The Base Product Meta-Model distills the minimal set of abstractions necessary to describe any product.
By separating core concepts (identity, versioning, ownership, interfaces, contracts, assets, provenance, evaluation) from domain extensions, the BPMM ensures that:

  • All products are comparable and interoperable.
  • Domain-specific descriptors remain extensible.
  • Unified marketplaces can support Data, AI, software, and physical products without duplication.

In conclusion:
The Base Product Meta-Model provides the structural foundation for the BPS. It ensures that every product can be described consistently, governed transparently, and extended flexibly, thereby addressing the fragmentation identified in earlier sections.