Print vertical for UCP: open vocabulary, schemas and product identity, ready to reference

[ptpge]

In short: a configured print product cannot be a SKU. Before a protocol can handle one, it needs shared terms for the buyer's choices and a stable identity for each configured product. PTPGE publishes both as open data, for whoever drafts the print vertical to reference rather than re-create.

Context

In May, Initiative Online Print, BVDM and Intergraf announced that they are drafting a print vertical for UCP (working title dev.ucp.print), with an enhancement proposal targeted for Q4 2026; CIP4, VIGC, dpsuisse, the Ghent Workgroup and PRINTING United Alliance have since joined. Their Problem & Opportunity Paper: https://initiative-online-print.de/wp-content/uploads/2026/05/UCP_Print_Industry_Problem_Opportunity_Paper_EN_v3.1_06.05.2026.pdf

The problem

A printed product only exists once the buyer has chosen format, pages, substrate, colour, finishing and quantity — millions of variants of one product. Every storefront, MIS and language names those choices differently. So a protocol needs two things first:

1. Shared meaning: the same choice means the same thing everywhere.
2. Stable identity: the same configured product gets the same identity everywhere.

What PTPGE provides

• Vocabulary. 732 terms and 56 product templates, each with a permanent URI. JSON-LD and Turtle, 12 languages, CC BY 4.0. Every binding is a URI or a number, never a label. Repository: github.com/ptpge/ptpge-specification
• Fingerprint. Each configured product gets one identity: a SHA-256 hash over a canonical string, recomputable by anyone. The request carries it, the quote repeats it, and the job nests it together with the artwork's hash.
• Schemas. Five JSON Schemas built on the vocabulary and the fingerprint: vendor-declaration/1, supplier-catalogue/1, request/1, quote/1 and ucp-manifest/1 — ptpge.org/v1/schemas
• UCP extension. org.ptpge.print.identity extends dev.ucp.shopping.checkout and is published in the org. tree. A reference storefront serves the manifest at /.well-known/ucp.
• MCP server. Read-only, in the official registry as org.ptpge/mcp-server, Apache 2.0. It validates and fingerprints a configuration.

One open question

Can a capability's schema declare a property whose values are URIs into an externally published and separately governed vocabulary — validated by pattern and resolution, not by an inline enum — or does UCP expect every value a capability depends on to be enumerated in source/? Lodging can inline its room types and rate plans because they are small. Print cannot: the vocabulary is too large, and it changes under its own governance.

Asked separately in Q&A: #972

Who we are

We publish a specification, not a vertical. The vocabulary and the identity are published so that a print vertical can reference them rather than re-create them, and we are available to that work — and to anyone in this repo looking for a use case beyond retail.

[awepthon]

Thank you for this, it is a useful precedent beyond print. Footwear faces the same question: the sizing vocabulary already exists in ISO/TC 137 (foot, last and in-shoe measurement), but UCP has no place for those numbers, and a vertical would need to reference that externally governed vocabulary rather than inline it. Following the answer to #972 with interest.

[ptpge]

Thank you — that is exactly the point, and footwear makes it better than print does: a sizing vocabulary with an ISO home, numbers rather than labels, and nothing in UCP that can hold them. #972 has since had a useful answer, grounded in the Schema Authoring Guide: URI-valued strings are fine, enum is for provably closed sets, and the capability must document membership, resolution and unknown-term handling. That is what org.ptpge.print.identity does, and it should carry over directly to ISO/TC 137 measures. Happy to compare notes if useful for a footwear proposal.