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 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:

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:

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:

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:

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: 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:

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:

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:

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 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; 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 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:

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.