--- title: "The Passport Editor" description: "One editor for products, organizations and places — ontology-generated forms, rich field widgets, GS1 validation, access levels and full version history." canonical_url: "https://openepcis.io/docs/digital-data-management/passport-editor" last_updated: "2026-08-26T20:11:08.978Z" --- ## One editor, three kinds of record Products, organizations and places are edited in one and the same passport editor — only the vocabulary behind the form changes with the record kind. That is not an implementation shortcut but a promise: whatever you learn on this page about validation, history or access levels holds everywhere in the catalog. ![The passport editor with the Details tab active | Figure 1: The editor — section rail (left), generated form (center), live JSON-LD pane (right)](/img/13.Digital-Data-Management/editor-details.png) The editor opens as a full-width drawer over the list and has three zones. On the left, the **section rail**: the form's sections with a count of filled fields each, so a long passport stays navigable. In the center, the **form** itself. And on the right — this is the part that surprises people coming from ordinary catalog tools — the **live JSON-LD pane**. ## The form and the record are the same thing In most applications, the form is one thing and "the data" is something else, hidden in a database, transformed on the way in and out. DDM collapses that distance. What you are editing *is* the record: a JSON-LD document in GS1 Web Vocabulary, and the pane on the right shows it to you, updating with every keystroke. Type a German product name into the form and you can watch it appear under `productName.de` in the document. Why show this at all? Because the document is what everything else consumes — the passport page, the API, a partner's system reading your data. Seeing it live means there is never a gap between what you think you entered and what the world will get. And for those who prefer working the other way around, the **JSON-LD tab** makes the document itself editable: ![The JSON-LD tab | Figure 2: The record as JSON-LD — edits here and in the form stay in step](/img/13.Digital-Data-Management/editor-json.png) Paste a record exported from another system, adjust a context, add a term the form does not surface — the form re-reads your JSON on every change, and both views stay in step. Values in the document that no loaded vocabulary describes are not lost or hidden either: they are listed in an *unmodeled terms* panel and survive every save cycle untouched, which is what makes DDM safe to use side by side with other tooling. The form itself stays out of your way. Only the sections relevant to the record are open by default (*"n more sections"* expands the rest), empty fields can be shown or hidden, and the **Search terms** palette (`Ctrl K`) jumps to any field — or adds any vocabulary term the form is not currently showing. ## The tabs Along the top of the drawer:
Tab What it holds
Details The generated form — where you edit fields
Links The record's resolver links, embedded from Linksets
Sync Outbound publication per channel — see GS1 Germany Sync
Changes Exactly what saving would write: added, removed and changed values
Versions Every saved version, newest first
JSON-LD The record as editable JSON-LD — two-way with the form
The **Changes** tab deserves a habit: before saving a record you have worked in for a while, glance at it. It shows the precise difference between the stored record and your working copy — the answer to "what am I actually about to publish?", before it happens: ![The Changes tab | Figure 3: One renamed product, shown as it will be written — old value left, new value right](/img/13.Digital-Data-Management/editor-changes.png) ## Fields that know what they hold Because every field is a vocabulary term with a declared datatype, each gets a widget that makes invalid input hard to produce in the first place. A few are worth introducing: **Localized text** is DDM's answer to multilingual passports. A product name is not one string but one per language — add rows with *Add language*, and the passport page later serves each visitor their language when the record carries it. **Measurements** pair a value with a UN/CEFACT unit, so a net content is `750 MLT`, never a bare number whose unit lives in a comment somewhere. The full UN/CEFACT code list ships with the editor — searchable by name and grouped by the kind of quantity, so "lit" finds *litre*, *litre per litre* and *litre per hour* without anyone memorizing `LTR`: ![The unit picker | Figure 4: Units are UN/CEFACT codes, found by typing the name](/img/13.Digital-Data-Management/editor-unit-picker.png) **Code lists** — countries, languages, vocabulary enumerations — come as searchable pickers rather than free text, because `DE` and `Germany` and `Deutschland` must not end up as three different values in your data. **References** are how records connect. A product's brand owner is not a typed-in company name but a reference to an [organization record](/docs/digital-data-management/organizations-and-places): the picker searches your catalog, and the field stores the target's GLN. The payoff comes later — when that organization's address changes, every product referencing it is current automatically, because the fact was stored once. **File uploads** put documents where URLs are expected: any URL field carries a paperclip (for holders of the `files-writer` role), and uploading a certificate or product image fills the field with its served address. And **nested objects** — an address, a contact point — unfold in place instead of sending you to a sub-dialog. ### Every field explains itself Because every field is a vocabulary term, the editor can put the term's own documentation right where you work. The ⓘ next to a label carries the **vocabulary definition** — the same text every other GS1-speaking system reads for this term, not a caption someone wrote for this form: ![A field definition tooltip | Figure 5: Hovering the ⓘ on Net content — the GS1 Web Vocabulary definition, in place](/img/13.Digital-Data-Management/editor-tooltip.png) The colored chip at a field's right edge names **where the term comes from**. DDM's vocabularies are assembled from several sources — the GS1 Web Vocabulary as the foundation, regulation modules such as *EU Battery* (Battery Regulation 2023/1542), *EU Packaging*, *EU Textile* and their siblings, plus the cross-cutting *OpenEPCIS Core* — and the editor shows that seam honestly instead of pretending everything is one vocabulary. A battery passport makes the layering visible: GS1 fields and regulation fields side by side, each wearing its source, each readiness profile counted separately: ![A battery passport form | Figure 6: One form, several source vocabularies — GS1 fields next to EU-Battery fields, two requirement profiles in the rail](/img/13.Digital-Data-Management/battery-provenance.png) The remaining badges follow the same idea — everything a field asserts about itself is hoverable: the *Recommended* badge names the regulatory clause behind it, and the tier badge (*Public* with a globe, *Restricted* with a lock) explains who will see the value and why. ### The GPC classification picker One field gets special treatment: `gpcCategoryCode`, the product's place in GS1's Global Product Classification. Nobody knows eight-digit brick codes by heart, so the picker searches by name and shows each brick's full path — enough context to tell *Juice – Ready to Drink* from its shelf-stable sibling: ![The GPC picker | Figure 7: Searching bricks by name — each hit shows its full classification path](/img/13.Digital-Data-Management/editor-gpc.png) ## Validation that explains itself The editor validates as you type, and its messages aim to be instructions, not verdicts. A GTIN with a wrong check digit tells you which digit it expected. A malformed date names the format. The footer keeps the honest total — *"n fields need attention"* — and only genuinely invalid values block a save. Requirements from the record's [passport template](/docs/digital-data-management/passport-templates) are shown as what they are: obligations, not gates. The readiness panel counts *"m of n requirements met"* and names what is missing, but an unmet *recommendation* never blocks a save — regulation compliance is a state you work towards, and the editor measures it rather than enforcing it prematurely. ## Access levels Every record carries an access level in the drawer's header — **Public**, **Authorized only** or **Restricted**. Think of it as the record's overall audience: a consumer product will be *Public*, a not-yet-launched one perhaps *Authorized only*. The finer instrument — deciding per *field* who sees what, so that the public sees the product name but only authorities see the manufacturing site — is [Field Access](/docs/digital-data-management/field-access); both work together on the passport page. ## EPCIS capture on resolve Products offer one opt-in that connects the passport world to supply-chain visibility: **Capture EPCIS events when this product is scanned**. With the toggle on, a scan of a *serialized or lot-level* Digital Link on one of [your domains](/docs/digital-data-management/resolver-domains) generates an EPCIS event at the domain's configured read point — each scan becomes a data point in the product's traceability record. Model-level scans (the bare GTIN) never capture, deliberately: only batch and item scans say something about a physical object's whereabouts. ## Versions & change history Every save creates a new version; nothing in DDM is ever silently overwritten. The **Versions** tab lists them newest-first, each with its timestamp and author: ![The Versions tab | Figure 8: Versions — every save is recorded; past versions open read-only](/img/13.Digital-Data-Management/editor-versions.png) Past versions open read-only, and that is a deliberate boundary rather than a missing feature: a history you could write back into would stop being a record of what was published. When a passport is the document a regulator or a consumer relied on at some point in time, "what did it say last March?" must have exactly one answer.