PTPGE Standard — Integration Guide

PTPGE Standard is the open vocabulary for the printing industry — a structured, multilingual, versioned reference under CC BY 4.0. This guide describes how to integrate it into your system, regardless of your tech stack.

Overview — what integrating means
Quick start (5 minutes)
Product Model (Layer 1)
Integration patterns — pick what fits
Example: e-commerce / marketplace
Example: MIS / ERP / workflow
Example: AI agents via MCP
Example: custom application
Best practices
Stability and versioning
API reference and resources

Overview — what integrating means

Integration with PTPGE Standard means making your system aware of the canonical vocabulary that the print industry uses to describe products, formats, substrates, technologies, features, and completions. There is no single right way to integrate; the right pattern depends on what your system does.

At minimum, integration means referencing PTPGE URIs in your data — for example, tagging a product in your catalog with https://ptpge.org/v1/printing/configurations/formats/a-series/a4 rather than a free-text "A4". This makes your data interoperable with any other PTPGE-aware system: marketplaces, AI agents, MIS systems, supplier directories.

At maximum, integration means mirroring the standard locally with full multilingual labels, structured properties, and external mappings — letting your system filter, search, and reason about products with full PTPGE semantic depth.

The minimum useful integration is one HTTP call. If your system can fetch https://api.ptpge.org/v1/printing/configurations/formats/a-series/a4 and store the URI as a reference, you have meaningful PTPGE integration.

Quick start (5 minutes)

1. Fetch a term

curl https://api.ptpge.org/v1/printing/configurations/formats/a-series/a4
# Returns: JSON-LD with the A4 term, labels and definitions in 12 languages,
# structured properties (width, height, area, aspectRatio), broader/narrower
# relations, and external mappings.

2. Browse the structure

curl https://api.ptpge.org/v1/printing/configurations/formats/a-series
# Returns the A Series category with all its narrower terms (A0, A1, A2, ...).
# Walking the tree from /v1/printing/ lets you discover the Printing Process
# (industry view) branch.

curl https://api.ptpge.org/v1/ordering/products
# Returns the Products Group under Ordering Process (end-user view).
# /v1/ordering/ holds end-customer concepts: products to buy, geography, knowledge.

3. Get the full bundle

curl https://api.ptpge.org/v1/terms.jsonld
# Returns all 780 terms (three top concepts) in a single JSON-LD @graph.
# Useful for clients that want to load everything once and query locally.
# Every term carries an axis-typed notation v3.0 (e.g. P:CF§A4, P:CP-FIN-LAMI,
# O:PR§TRI-FOLD-BROCHURE, V:DM§FORMAT) and leaf elements carry an elementType.

4. Plain-JSON variant

curl 'https://api.ptpge.org/v1/printing/configurations/formats/a-series/a4?format=json'
# Same payload, served with Content-Type: application/json instead of
# application/ld+json — for clients whose HTTP libraries don't recognise
# application/ld+json as JSON.

5. Reference in your data

Once you can fetch terms, the integration step is to reference PTPGE URIs in your own product / catalog / order data. For example, a configured product that binds a Brochure Template (Layer 1) to specific choices (Layer 2 Configurator):

{
  "id": "your-product-12345",
  "name": "A4 single-fold brochure for product launch",
  "ptpge_template": "https://ptpge.org/v1/ordering/products/configurable/sheets/brochures",
  "ptpge_setup_model": "https://ptpge.org/v1/ordering/setup-models/folded-sheet/single-fold",
  "selections": {
    "format": "https://ptpge.org/v1/printing/configurations/formats/a-series/a4",
    "orientation": "https://ptpge.org/v1/printing/configurations/orientations-shapes/portrait",
    "sections": {
      "outside": {
        "color_mode": "https://ptpge.org/v1/printing/features/colors/cmyk",
        "surface_finish": "https://ptpge.org/v1/printing/completions/finishing/laminations/matte"
      },
      "inside": {
        "color_mode": "https://ptpge.org/v1/printing/features/colors/cmyk"
      }
    }
  },
  "your_internal_sku": "BR-A4-MA200-OFF-CMYK"
}

You're now PTPGE-aware. Any other system that speaks PTPGE can interpret your data correctly. See Product Model below for the full model spec.

Product Model (Layer 1)

The PTPGE Product Model (v1.0, 2026-05-20) defines how printed products are represented at Layer 1. A Product Template is a Layer 1 SKOS concept that describes a class of printed products — not a single sellable variant. Configurators (Layer 2), applications (Layer 4), and AI agents consume Templates to instantiate concrete product configurations.

The canonical reference is PTPGE-Product-Model.md (15-section specification). This section is a fast overview for implementers.

The four-block Template structure

Every Product Template carries exactly four blocks of Layer 1 information:

Setup Model — single URI reference to a topology (flat-sheet, folded-sheet variants like single-fold / tri-fold / accordion-fold, multi-page variants like saddle-stitched). Defines the Surface structure.
Supports — 18 constraint predicates declaring which values from the Printing Process vocabulary the Template is compatible with (supportsFormat, supportsSubstrate, supportsTechnology, etc.).
Per-Surface Supports — 3 predicates declaring which Color Layer / Embellishment / Surface Finish choices can vary independently per Surface (perSurfaceSupportsColorMode, perSurfaceSupportsEmbellishment, perSurfaceSupportsSurfaceFinish).
Typical Properties — descriptors via controlled vocabularies (typicalUse / typicalAudience as URI references into /v1/ordering/use-cases/ and /v1/ordering/audiences/) plus literals (typicalPageCount, fulfilmentClass).

Granularity principle

One Layer 1 Template = one Setup Model. When Setup Model changes, a new Template is justified. All format / orientation / fold-direction variation is supports*-data resolved by the Configurator at Layer 2.

For example, brochures consist of 13 Templates — one per fold mechanism (single-fold, tri-fold, z-fold, gate-fold variants, accordion-fold, tri-fold-stand, double-parallel-fold, cross-fold, cross-tri-fold, roll-fold). Each format and orientation choice is supports-data, not a new Template.

Surface semantics

A Surface is the canonical addressable unit: one Surface = one substrate-side = one Print Layer Stack (Color Layer → Embellishment → Surface Finish). A flat-sheet has 2 Surfaces (Front, Back); a single-fold brochure has 2 Surfaces (Outside, Inside) each with 2 panels; a saddle-stitched booklet has 6 Surfaces (Front Cover, Inside Front Cover, Outside Pages, Inside Pages, Inside Back Cover, Back Cover).

Notation convention (v2.0)

Notations are Printing Process only. Ordering Process terms (products, audiences, geography) have no notation — they're referenced by URI or label. Two separators distinguish the two roles a notation plays:

Dash (-) for structural levels — groups, categories, sub-categories. Hierarchical encoding, each level adds 1 char.
Silcrow (§) for leaf elements. Flat form: GROUP§ELEMENT. Mirrors the periodic table metaphor.

Length-by-level for structural levels:

Group: 2 chars (CF, CP, ST, MG, TC, FT, SB)
Category: 3 chars (CF-FMT, CP-FIN, ST-CER)
Sub-category: 4 chars (CF-FMT-ASER, CP-FIN-LAMI, ST-CER-ENVR)
Deeper levels add 4-char segments (SB-SHT-PAPR-PSUP-LESS)

Leaf elements are flat — not hierarchical: CF§A4 (not CF-FMT-ASER§A4), CP§GLOSS, FT§CMYK, ST§ISO12647-7, SB§SCANDIA-SMOOTH-IVORY (brand-prefixed for paper supplier products). The URI carries the full hierarchy; the notation is the periodic-table-style shorthand.

Layer 2 boundary — what's excluded from the Template

The Layer 1 Template does not include:

Pricing (vendor data, Layer 4 application concern)
Quality tiers ("Premium" vs. "Standard" — same Template, different supports*-selections)
Vendor-specific variants (what each vendor actually offers — Layer 2 Configurator-binding)
Marketing names ("Executive Card" — vendor presentation layer)

For full specification, including the worked example for Single-Fold Brochure and the relationship to XJDF / dev.ucp.print, see PTPGE-Product-Model.md.

Integration patterns — pick what fits

Four patterns cover most integration use cases. They differ in how much of the standard you mirror locally vs. fetch on demand.

Pattern A — Reference only

Lightest Just store PTPGE URIs in your data. Fetch term details from the API on demand when you need to display labels or definitions. Suitable for: small catalogs, prototypes, low-traffic systems.

Pattern B — Local mirror with sync

Most common Maintain a local copy of all PTPGE terms in your database, refreshed by a scheduled sync job (e.g. daily). Reference by URI but resolve labels and properties locally for fast queries. Suitable for: marketplaces, MIS systems, anything with significant query volume.

Pattern C — Embedded snapshot

Offline-friendly Bundle a snapshot of the PTPGE Standard as data inside your application (e.g. a JSON file shipped with your product). Suitable for: desktop applications, mobile apps, MIS systems that operate disconnected, or systems requiring no external dependencies.

Pattern D — AI agent access via MCP

AI-native Use the PTPGE MCP (Model Context Protocol) server to give AI agents (Claude, ChatGPT, Microsoft Copilot, custom agents) direct access to PTPGE Standard. Agents can query, search, and reason about print industry concepts without any custom integration on your side. Suitable for: AI-driven workflows, conversational interfaces, agent-based automation.

Example: e-commerce / marketplace

An e-commerce or marketplace platform integrating PTPGE typically uses Pattern B (local mirror with sync). The pattern below applies to any platform — WooCommerce, Shopify, Magento, custom — with adjustments for the platform's data model.

Architecture

PTPGE Standard (api.ptpge.org)
        │
        │  daily sync job (HTTP GET)
        ▼
Local PTPGE term cache (your database)
        │
        ▼
Product catalog references PTPGE URIs as
attribute terms / category tags / metadata

Integration steps

Define a sync schema. Each PTPGE term becomes a row in your local terms table, with the URI as primary key and label/definition fields in your supported languages.
Implement the sync job. A daily cron-style job fetches api.ptpge.org/v1/version.json, compares against the locally stored version, and if different, fetches api.ptpge.org/v1/terms.jsonld to update the local cache. Diff sync — only changes are written.
Map products to PTPGE terms. When a product is created, its category / format / substrate / etc. references PTPGE URIs. The exact mechanism depends on your platform: WooCommerce uses attribute taxonomies, Shopify uses metafields, Magento uses EAV attributes.
Expose products as PTPGE-conformant. Your product API or storefront emits structured data (JSON-LD) with PTPGE references, making products discoverable and interpretable by AI agents and external integrators.

WooCommerce example

For WooCommerce-based shops and marketplaces, each PTPGE group becomes a WooCommerce attribute taxonomy:

pa_ptpge_format       (Configurations, ~119 terms)
pa_ptpge_substrate    (Substrates, ~75 terms)
pa_ptpge_technology   (Technologies, ~98 terms)
pa_ptpge_features     (Features, ~32 terms)
pa_ptpge_completion   (Completions, ~43 terms)

Each attribute term carries the PTPGE URI as term meta. Products select attributes through the standard product-editing flow; PTPGE references derive automatically.

Layer 2 Configurator resolution

A marketplace UI typically resolves a Product Template (Layer 1) plus buyer-selected choices into a concrete product configuration that vendors can quote and fulfil. The pattern:

// 1. Load the Template by URI (cached locally)
template = cache.get("https://ptpge.org/v1/ordering/products/configurable/sheets/brochures")

// 2. Bind a topology from supportsSetupModel (a Variable binding —
//    variables/structure/setup-model), then resolve it for the Surface structure
setup = cache.get(buyer_choice ?? template.supportsSetupModel[0])
// setup.surfaces = [{id: "outside", panels: [...]}, {id: "inside", panels: [...]}]

// 3. Surface buyer choices from supports* arrays
format_options    = template.supportsFormat         // 8 formats
orientation_opts  = template.supportsOrientation    // 3 orientations
fold_direction    = template.supportsFoldDirection  // 2 directions

// 4. Per-Surface choices from perSurfaceSupports* arrays
for each section in setup.sections:
    color_options = template.perSurfaceSupportsColorMode      // 6 color modes
    embellishments = template.perSurfaceSupportsEmbellishment // 5 options
    surface_finish = template.perSurfaceSupportsSurfaceFinish // 5 options

// 5. Compose the configured product and query vendors
configured_product = {
    template: template.id,
    format: chosen_format_uri,
    orientation: chosen_orientation_uri,
    sections: chosen_section_configurations,
    typicalUse: template.typicalUse,       // for analytics/matching
    typicalAudience: template.typicalAudience,
}
quotes = vendor_api.quote(configured_product)

The marketplace stores the configured product (not the Template) in the cart and order. Vendors receive PTPGE URIs everywhere; no marketplace-specific format is needed for vendor integrations.

Example: MIS / ERP / workflow

Print MIS systems (Heidelberg Prinect, Kodak Prinergy, EFI Fiery, Esko Automation Engine, Agfa Apogee, custom MIS) typically integrate PTPGE as a reference vocabulary layer alongside existing internal codes. PTPGE complements JDF and ICC profiles rather than replacing them.

Crosswalk pattern

Most MIS systems already have internal codes for products, formats, substrates, etc. The recommended pattern is a crosswalk: keep internal codes as primary, add a PTPGE URI mapping as a secondary reference.

Internal MIS code → PTPGE URI mapping table:

INT-FORMAT-A4         → ptpge.org/v1/.../a4
INT-FORMAT-LETTER     → ptpge.org/v1/.../letter
INT-SUBSTRATE-MA200C  → ptpge.org/v1/.../matt-200gsm-coated
INT-PROCESS-OFFSET    → ptpge.org/v1/.../offset

This is a few engineering weeks of catalog mapping work — not a re-architecture. The MIS continues to operate on internal codes; PTPGE URIs flow through to customer-facing and supplier-facing exchanges.

JDF / XJDF integration

For MIS systems that produce or consume JDF or XJDF, PTPGE URIs can be carried in custom extension elements. Each JDF Resource that has a PTPGE equivalent references the URI:

<ResourcePool>
  <Component DescriptiveName="A4 brochure">
    <ptpge:Template>https://ptpge.org/v1/ordering/products/configurable/sheets/brochures</ptpge:Template>
    <ptpge:SetupModel>https://ptpge.org/v1/ordering/setup-models/folded-sheet/single-fold</ptpge:SetupModel>
    <ptpge:Format>https://ptpge.org/v1/printing/configurations/formats/a-series/a4</ptpge:Format>
  </Component>
</ResourcePool>

PTPGE Surfaces ↔ XJDF Side-partitioning

PTPGE's per-Surface model maps cleanly to XJDF resource partitioning. PTPGE declares the addressable Surfaces explicitly (Front Cover, Inside Pages, Outside, etc.); XJDF partitions resources along axes (Side, SectionIndex, SheetName). The two are complementary — PTPGE is the product conception vocabulary, XJDF is the production execution model.

// PTPGE Layer 1 Template (high-level, abstract)
{
  template: "https://ptpge.org/v1/ordering/products/configurable/sheets/brochures",
  perSurfaceSupportsColorMode: {
    outside: ["cmyk", "cmyk + pantone-spot"],
    inside:  ["cmyk", "black-only"]
  },
  perSurfaceSupportsEmbellishment: {
    outside: ["spot-uv-varnish", "foil-stamping/gold"]
  }
}

// Maps to XJDF Resource partitioning (production-execution)
<ColorantControl>
  <ColorantControl Side="Front">CMYK,Pantone 286 C</ColorantControl>
  <ColorantControl Side="Back">CMYK</ColorantControl>
</ColorantControl>
<SurfaceCoating>
  <SurfaceCoating Side="Front" Area="Spot">UV-Gloss</SurfaceCoating>
</SurfaceCoating>

A Layer 2/3 integration writes the XJDF partitioning from PTPGE per-Surface declarations. The exact mapping is documented in the dev.ucp.print Technical Brief Appendix B (XJDF Resource bindings).

Example: AI agents via MCP

The PTPGE MCP (Model Context Protocol) server makes the standard directly accessible to AI agents — Claude Desktop, ChatGPT custom GPTs, Microsoft Copilot (when MCP support ships), Anthropic API consumers, and any agent platform that supports MCP.

What an agent can do

With MCP integration, an AI agent can:

Search PTPGE terms in natural language ("find all formats with width near 200 mm")
Resolve a free-text query to a canonical PTPGE URI ("what's the standard business card size in Japan?" → 91 × 55 mm meishi format)
Walk the hierarchy ("list all completions related to binding")
Compare formats across regions ("how does ISO 216 A4 differ from US Letter?")
Generate PTPGE-conformant product specifications from natural-language briefs

Configuring MCP in your AI stack

The server speaks the Streamable HTTP transport (stateless JSON) at /mcp — the transport modern MCP clients prefer. In Claude (Desktop or claude.ai): Settings → Connectors → Add custom connector with the URL:

https://open.mcp.ptpge.org/mcp

Claude Code: claude mcp add --transport http ptpge https://open.mcp.ptpge.org/mcp. ChatGPT: Settings → Apps & Connectors with the same URL. Technical verification without any client: npx @modelcontextprotocol/inspector.

For other agent platforms, refer to their MCP documentation. The PTPGE MCP server is read-only and free to use under CC BY 4.0 attribution. During the Open Beta, request tracked credentials at register.ptpge.org. To try it without credentials, add the anonymous mirror at open.mcp.ptpge.org/mcp.

The MCP tools

The v1 MCP surface exposes seven read-only tools. The first three cover the vocabulary; the next four help an agent compose and check a product configuration against the Standard — all free under CC BY 4.0.

Vocabulary

ptpge_search_terms — Free-text search across the vocabulary. Returns ranked hits with URI, notation, prefLabel, level, group, and score. Supports group filters and result limits.
ptpge_get_term — Full context for one term: definition, broader/narrower/related relations, exactMatch/closeMatch mappings, properties, notation, level, and metadata. Accepts full URI or relative path.
ptpge_get_version — Vocabulary version metadata: dataVersion, schemaVersion, term counts per level and per group, license, scheme URL, and server version.

Product & configuration

ptpge_browse — Hierarchy navigation: the children of any node (or the top concepts when called with no arguments). Walk the tree without pre-loading the full bundle.
ptpge_get_product_envelope — The complete Configuration Envelope of a product class in one call, with resolved labels — saves an agent 10+ ptpge_get_term round-trips when composing a product. An envelope is the served, checkable form of a configuration space — the product template's full space at Layer 1, or a producer's narrowed space in their capability profile.
ptpge_validate_config — Layer 1 envelope validation: checks a set of bindings against the template's supports* constraints (including numeric gsm → weight band via minWeight / maxWeight, plus data-driven advisories). Deliberately not full legality checking — deeper producibility and cross-vendor capability matching is the metered Layer 3 Engine; this free Layer 1 tool demonstrates the mechanics.
ptpge_fingerprint — Canonical ptpge-cfs/1 serialization + SHA-256 of a configuration, in both profiles (spec / offer), per SD-0040. A deterministic, verifiable identity for any configured product.

Typical agent workflow

# Agent receives: "I need to print 500 tri-fold brochures, A4, full color"

# 1. Search for product type
search_result = ptpge_search_terms(query="tri-fold brochure")
# Returns: brochures — one consolidated product; fold topologies via supportsSetupModel (SD-0038)
# Brochures live under /v1/ordering/.../brochures/ — Ordering side, no notation.

# 2. Get the Template
template = ptpge_get_term(uri="https://ptpge.org/v1/ordering/products/configurable/sheets/brochures")
# Returns: full Vei D structure with supportsSetupModel, supports*, perSurfaceSupports*

# 3. Validate buyer choices against supports*
# - format: A4 ∈ template.supportsFormat ✓
# - color: CMYK ∈ template.perSurfaceSupportsColorMode (per Surface) ✓
# - quantity 500: not a Layer 1 constraint (passed through)

# 4. Compose configuration and pass to marketplace/vendor system
configured_product = build_from_template(template, choices)

The MCP server is read-only and free to use under CC BY 4.0 attribution. Apply for credentials at register.ptpge.org during the Open Beta.

Example: custom application

For custom applications — internal tools, partner integrations, prototypes — the integration pattern is dictated by your stack. Below are minimal-effort examples for common runtimes.

Python

import requests

# Fetch a term
r = requests.get("https://api.ptpge.org/v1/printing/configurations/formats/a-series/a4")
term = r.json()
print(term["label"]["en"])   # "A4"
print(term["properties"])    # {"width": 210, "height": 297, "unit": "mm", ...}

# Search local cache (after one-time download of terms.jsonld)
all_terms = requests.get("https://api.ptpge.org/v1/terms.jsonld").json()
formats = [t for t in all_terms["@graph"] if t.get("group") == "configurations"]

JavaScript / Node.js

const term = await fetch(
  "https://api.ptpge.org/v1/printing/configurations/formats/a-series/a4"
).then(r => r.json());

console.log(term.label.en);      // "A4"
console.log(term.properties);    // { width: 210, height: 297, unit: "mm", ... }

Browser (with CORS)

The API supports CORS for any origin. You can fetch terms directly from client-side JavaScript:

fetch("https://api.ptpge.org/v1/printing/configurations/formats/a-series/a4")
  .then(r => r.json())
  .then(term => console.log(term));

RDF / SPARQL

The full term bundle is valid RDF (via JSON-LD). Load it into Apache Jena, RDFLib, or any SPARQL endpoint:

# Python with rdflib
from rdflib import Graph
g = Graph()
g.parse("https://api.ptpge.org/v1/terms.jsonld", format="json-ld")

# Query: all elements in the Configurations group
sparql = (
    "PREFIX skos: <http://www.w3.org/2004/02/skos/core#> "
    "SELECT ?term ?label WHERE { "
    "  ?term a skos:Concept ; "
    "        skos:prefLabel ?label ; "
    "        ?_ <https://ptpge.org/v1/group> 'configurations' . "
    "  FILTER (lang(?label) = 'en') }"
)
results = g.query(sparql)

Semantics of absence (SD-0068)

Absence means three different things at three layers — integrators should rely on all three:

Templates (envelopes) — closed world. An absent supports* predicate means not supported. No «none»-values exist or are needed at template level.
Configurations (ptpge-cfs/1 bindings) — partial statements. An unbound variable means unspecified, never «none». Partial configurations are valid identities, and matching treats unbound axes as unconstrained.
features/colors/none — spoken blankness. The one legitimate none-value, because surfaces exist regardless of choice: «this surface shall carry no ink» (4/0 work, blind embossing, spot UV on bare stock) is a positive, identity-bearing statement, distinct from «not decided yet». Primarily surface-scoped (color-mode@<surface>=none). No none-values exist on any other axis — lamination, foil, binding and the like are additive processes, where unmentioned simply means not part of the product.

Rule of thumb: «None» exists only where something physical exists regardless of what you choose.

Best practices

Always reference URIs, not labels

Labels ("A4", "Offset") are convenient for display but can change between versions. URIs (https://ptpge.org/v1/.../a4) are permanent. Reference URIs in your data; resolve labels for display.

Cache, don't poll

The standard changes infrequently — typically a few times per month at most. Sync once a day; do not query the API for every product page render.

Track the version you've synced

Store the PTPGE Standard version (2026-05-08 format) you've cached locally. When syncing, compare against the live version and only update if different.

Plan for deprecated terms

PTPGE terms are never deleted — URIs are permanent. But terms can be marked deprecated when the industry concept itself becomes obsolete. Your data referencing a deprecated term remains valid; surface a warning when users see deprecated values.

Honour the CC BY 4.0 attribution

The standard is freely usable, including commercially, but attribution is required. Include "PTPGE Standard, ptpge.org" in your developer documentation or terms of service.

Use cross-references when relevant

PTPGE terms have exactMatch and closeMatch mappings to Wikidata, Schema.org, GS1 GPC, and other vocabularies. If your system already uses one of those, the PTPGE crosswalk lets you translate between vocabularies without manual mapping work.

Polylang / multilingual: URI is shared, labels translate

For multilingual systems, store one URI per concept and use the language-specific label fields (label.en, label.nb, label.de, label.ja, label.es, label["zh-Hans"], label.sv, label.da, label.nl, label.pl, label.pt, label.hi) for display — twelve languages today; ptpge:translationStatus on /v1/scheme says which are production and which are LLM drafts pending review. The URI never changes between languages.

Notation is for Printing Process

Only Printing Process terms (technologies, substrates, features, completions, standards, management, configurations) carry a notation. Ordering Process terms (products, audiences, geography) are referenced by URI or label.

Two separators distinguish notation roles: dash (-) for structural levels in hierarchical form (CF, CF-FMT, CF-FMT-ASER), and silcrow (§) for leaf elements in flat form (CF§A4, CP§GLOSS, FT§CMYK, ST§ISO12647-7). The silcrow signals "destination element" — a stable identifier suitable for SKUs and external references. Brand-anchored leaves carry the brand explicitly: SB§SCANDIA-SMOOTH-IVORY, TC§XEROX-IRIDESSE-PRODUCTION-PRESS.

Honour Surface structure when generating production specs

Products that use a Folded Sheet or Multi-page Setup Model carry an addressable Surface structure (one Surface = one substrate-side = one Print Layer Stack). When generating XJDF or JDF, map Surfaces to Side / SectionIndex partitions rather than collapsing them. PTPGE-aware production lets each Surface carry independent color mode, embellishment, and surface finish — a capability that matters for premium brochures, multi-cover catalogues, and reveal-style marketing pieces.

Stability and versioning

URI stability is sacred. Once a PTPGE URI is published, it never changes. Term labels can be edited; structured properties can be added; definitions can be refined. The URI itself is permanent for the lifetime of the standard.

What can change between versions

Term labels (typo fixes, refinements)
Term definitions (clarifications, additional languages)
Structured properties (new properties added; existing properties may be re-typed in major versions)
Cross-references (new exactMatch / closeMatch additions)
New terms (added to the standard)

What never changes

Term URIs
The structural model (Groups → Categories → Sub-Categories → Elements)
The CC BY 4.0 license
The JSON-LD context base structure

Version cadence

Patch versions: typo fixes, new translations, new exactMatch references. Released as needed.

Minor versions: new terms, new properties, new languages. Released every 1–3 months.

Major versions: structural changes (rare; never planned). Would be backward-compatible via cross-references; never breaks existing URIs.

Subscribe to the PTPGE Changelog for notifications of every version bump.

API reference and resources

Resource	URL
Public API root	`https://api.ptpge.org/v1/`
Discovery document	`https://api.ptpge.org/v1/`
Concept scheme	`https://api.ptpge.org/v1/scheme`
JSON-LD context	`https://api.ptpge.org/v1/context`
Full term bundle	`https://api.ptpge.org/v1/terms.jsonld`
Search index	`https://api.ptpge.org/v1/search-index.json`
Version metadata	`https://api.ptpge.org/v1/version`
Changelog	`https://api.ptpge.org/changelog.html`
License	CC BY 4.0

Data formats

Default: application/ld+json (JSON-LD 1.1)
Plain JSON: append ?format=json to any endpoint for clients that don't recognise application/ld+json as JSON
HTML: any term URL serves human-readable HTML when accessed from a browser (Accept-header content negotiation)

Support and questions

For integration support, technical questions, or issues, contact api@ptpge.org. The standard is maintained by GutenLex Technologies AS, which is committed to transferring the Standard to an independent, non-profit PTPGE Foundation.

PTPGE Standard — Integration Guide

On this page

Overview — what integrating means

Quick start (5 minutes)

1. Fetch a term

2. Browse the structure

3. Get the full bundle

4. Plain-JSON variant

5. Reference in your data

Product Model (Layer 1)

The four-block Template structure

Granularity principle

Surface semantics

Notation convention (v2.0)

Layer 2 boundary — what's excluded from the Template

Integration patterns — pick what fits

Pattern A — Reference only

Pattern B — Local mirror with sync

Pattern C — Embedded snapshot

Pattern D — AI agent access via MCP

Example: e-commerce / marketplace

Architecture

Integration steps

WooCommerce example

Layer 2 Configurator resolution

Example: MIS / ERP / workflow

Crosswalk pattern

JDF / XJDF integration

PTPGE Surfaces ↔ XJDF Side-partitioning

Example: AI agents via MCP

What an agent can do

Configuring MCP in your AI stack

The MCP tools

Typical agent workflow

Example: custom application

Python

JavaScript / Node.js

Browser (with CORS)

RDF / SPARQL

Semantics of absence (SD-0068)

Best practices

Always reference URIs, not labels

Cache, don't poll

Track the version you've synced

Plan for deprecated terms

Honour the CC BY 4.0 attribution

Use cross-references when relevant

Polylang / multilingual: URI is shared, labels translate

Notation is for Printing Process

Honour Surface structure when generating production specs

Stability and versioning

What can change between versions

What never changes

Version cadence

API reference and resources

Data formats

Support and questions