Identifiers when there is only one of the thing

01

What an identifier field is asking

Applies to marketplace onlyown storefronthybrid

Commerce vocabularies in current use were built around manufactured goods, and the field names reflect it. Current product specifications require stable product and variant identifiers alongside price, availability, condition, media, and seller links.¹ The term “variant” carries the assumption: a thing that comes in sizes and colors, of which a shop holds several.

For a one-of-one seller, the implied question and the literal one differ. An identifier field asks which manufactured product this is. For a 1978 camera body the answer has two parts: which model it is, and which surviving example of that model is in hand.

02

Three identities and what each survives

Applies to marketplace onlyown storefronthybrid

Three separate identifiers are held, and each one outlives a different set of events. The vocabularies already model two of them: Schema.org represents a product as a described thing,² and an offer as the commercial terms under which it is sold.³ The middle term, the specific object, is supplied by the seller.

With the three distinct, the common operations resolve without convention. Repricing touches the offer. Relisting creates a new offer for the same object. Merging two accidental duplicates is a statement about objects that leaves both models and offers untouched.

03

When no manufacturer code exists

Applies to marketplace onlyown storefronthybrid

Resale stock frequently predates barcodes, was never assigned one, or has lost its packaging. Feeds and forms still request one. The options below are ordered by what each states about the object.

• A real manufacturer code on the object: use it, and record where it was read.
• The model has a code but this unit’s is unreadable: record the model-level code, noting that the unit was not verified against it.
• The item predates or falls outside the coding scheme: leave the field empty and record the reason where the destination accepts one.
• A minted, plausible-looking code: this states that the object is a different product, and the statement travels with the record.

The fourth option is the one an empty required field invites, since a blank can reduce eligibility on a destination and a filled field does not. The two costs are different in kind: an empty field can cost a placement, and a substituted one puts an inaccurate identification into every system that reads the record.

04

Two records, one object

Applies to marketplace onlyown storefronthybrid

Duplicate object records arise from stock entered from two places, an item re-entered after a return, or a bulk import run twice. The consequence is specific: two records for one object can each be marked available, and each will accept a buyer without consulting the other.

A duplicate is resolved by choosing one surviving object identity and redirecting the retired one to it, rather than deleting it. Anything still holding the retired identifier — an old listing, a saved link, a downstream copy — can then resolve to the survivor. Deleting the retired record removes that path.

This is a merge rather than a relist. A relist keeps the object and changes the offer. A merge records that two identifiers were describing one object. A system treating the two identically can reprice one object twice or return a sold one to availability.

05

Channel identifiers are references

Applies to marketplace onlyown storefronthybrid

Each destination assigns its own identifier to a listing, and each is a reference to the object rather than a replacement for it. The seller’s own object identity is what makes cross-surface reconciliation possible: when a sale happens on one channel, that identity is the key that locates every other place the same physical thing is advertised.

Where a channel identifier is used as the internal key, delisting and relisting issues a new one. The record then splits, and the object’s inspections, prior offers, and provenance notes remain attached to an identifier that is no longer current.

06

Adding identity to stock already listed

Applies to marketplace onlyown storefronthybrid

Retrofitting runs in a specific order, since assigning identity before reconciling duplicates preserves the duplication. Live records come first, because those are the ones a buyer can act on. Recently sold items follow, while a dispute or return is still open. Historic stock can come last.

1. Assign an object identifier to every currently live item and record it beside each channel listing ID.
2. Reconcile duplicates before continuing, since assigning identity to duplicates carries the duplication forward.
3. Backfill recently sold items so returns and disputes resolve to one object.
4. Write the intake rule, so the backlog stops growing during the work.

Completed for the camera, the map has four lines, one of which stays blank.

The blank carries its reason, so it can be revisited in a minute if paperwork appears. A number typed to clear a required field cannot afterwards be distinguished from a real one, including by the person who entered it.

The fourth step is what keeps the first three from repeating. The intake rule is one sentence: nothing enters stock without an object identifier assigned at the point of entry.

07

Identity as the sources define it

Applies to marketplace onlyown storefronthybrid

Current product specifications require stable product and variant identifiers.¹ The vocabularies represent a product as a described thing² and an offer as the terms of sale.³ None of them defines an identifier for the specific physical object, which is the value a seller of unique stock assigns and maintains.

The cited documents also do not state what a destination should do with an empty manufacturer-code field, so eligibility in that case is set by each destination’s own current requirements rather than by the vocabularies.