An Illustrative Object Attribute Schema for Robot-Ready Product Data

What a schema has to settle before you buy

A product feed written for a storefront is not a robot-ready record. Titles are marketing prose, units are mixed, case and each-level measurements share a field, and a blank can mean "unknown", "not applicable" or "nobody entered it". Agreeing a schema before purchase lets you reject a delivery on field-level grounds rather than argue about quality afterward.

Catalog-derived research data shows how thin attributes can be. ABO attaches up to 18 metadata attributes per product to 147,702 listings and 398,212 catalog images, with artist-made 3D meshes for only 7,953 products (Collins et al., 2021). A schema has to allow honest nulls, because commercial catalogs often resemble that pattern: broad on basic fields and deep for a minority of products.

This page is the field-level view. The measurement values themselves are covered in product dimensions and weights, and the properties catalogs rarely hold are in physical property annotations.

Design rules

1. Three levels of identity. A product (what a GTIN names), a packaging level (each, inner pack, case, pallet) and an instance (one physical unit that was photographed or scanned). Attributes attach to the level they describe. Cases and pallets also have their own unit-level key: the Serial Shipping Container Code identifies a logistic unit such as a case, pallet or parcel (GS1), which is not the same thing as the product identifier.
2. Values are objects, not bare numbers. Each measured or inferred value carries a unit, a source class (nominal, measured, estimated), a method and a date. The three source classes are explained in the dimensions page; the schema only has to carry them.
3. Closed vocabularies with explicit unknown and not_applicable. A blank field fails validation. If a supplier cannot say whether an item is fragile, the record says unknown.
4. Taxonomy codes carry scheme and release. GS1's Global Product Classification is a four-tier hierarchy of Segment, Family, Class and Brick with 8-digit codes. Only one brick can be assigned to a GTIN, and the brick groups products of similar form and material that share category attributes (GS1 GPC). The standards repository lists release 2026-05, so store the release with the code. UNSPSC is an open, multi-sector scheme with eight-digit codes across four levels (Segment, Family, Class, Commodity) (UNDP). Keep both, plus your own label scheme, in a crosswalk; product taxonomies for labels covers the mapping.
5. Measurements use a published vocabulary where one exists. The GS1 Package and Product Measurement Standard defines nominal measurement attributes from consumer unit to pallet, with release 3.3 ratified in August 2026, and GDSN lets trading partners share this master data through certified data pools (GS1, 2026). Ask the supplier which release its feed follows and map to those attribute names rather than inventing new ones.
6. Assets are referenced, not embedded, and each has a checksum. The Auto Care Association's PIES 8.0, released in April 2026, added digital asset file hashing to a standard that carries product attributes, descriptions, images and packaging (Auto Care Association). Copy the idea: a hash per file lets you verify a delivery.
7. Rights attach to assets and text fields, not to the whole record. One record can mix a studio's photograph, a brand's description and a retailer's own measurements.
8. Versions have dates. Packaging changes create a new valid-from date rather than overwriting the old record, so stale images can be found.

Illustrative schema

# Illustrative only — synthetic identifiers and values.
# R = required, C = conditional, O = optional. "src" is nominal | measured | estimated.
schema_version: "0.3"
product:
  product_id: prod_000123              # R  buyer-assigned, stable across deliveries
  gtin: "00000000000000"               # C  at least one of gtin / sku / mpn
  sku: "SKU-058-00123"                 # C
  mpn: null                            # C
  variant_of: prod_000120              # O  size or flavor family
  title: "Spray cleaner, citrus, 750 ml"   # R
  valid_from: 2025-11-01               # R  start of this packaging version
  valid_to: null                       # O
taxonomy:                              # R  one or more entries
  - {scheme: gpc, level: brick, code: "1xxxxxxx", release: "2026-05"}   # placeholder: GPC brick codes are 8 digits starting with 1
  - {scheme: buyer_v1, level: leaf, code: "cleaning/spray/trigger", release: "v1"}
packaging_levels:                      # R  at least "each"
  - level: each                        # each | inner_pack | case | pallet
    parent_level: case
    units_per_parent: 8
    axis_convention: "height = upright on shelf"
    length_mm: {v: 72,   src: nominal,  date: 2025-11-01}
    width_mm:  {v: 72,   src: nominal,  date: 2025-11-01}
    height_mm: {v: 248,  src: measured, method: dc_dimensioner_04, n: 6, date: 2026-03-02}
    gross_weight_g: {v: 1134, src: nominal, date: 2025-11-01}
    net_content: {v: 750, unit: ml, src: nominal}
physical:                              # O  default unknown; never guessed from category
  material_primary: hdpe               # closed vocabulary
  rigidity: semi_rigid                 # rigid | semi_rigid | flexible | unknown
  deformable: false                    # true | false | unknown
  transparent: false
  reflective: partial                  # none | partial | high | unknown
  fragile: unknown
  contents_state: liquid               # solid | liquid | powder | mixed | none | unknown
  center_of_mass_mm: null              # null = not held
  friction_coefficient: null
  hazard_flags: unknown
handling:                              # O
  orientation_sensitive: true
  stackable: true
  temperature_zone: ambient            # ambient | chilled | frozen | unknown
assets:                                # R for the asset types ordered
  - {asset_id: img_000123_front, type: image, view: front, file: images/000123_front.png,
     sha256: "<64-hex>", packaging_version: pv_2025_11, license_ref: lic_R07_studio, captured_at: 2025-11-12}
  - {asset_id: mesh_000123, type: mesh, format: glb, file: meshes/000123.glb,
     sha256: "<64-hex>", scale_checked: true, license_ref: lic_R07_scan}
sim_refs:                              # O  pointers to separate simulation assets
  - {format: usd, asset_id: sim_000123_usd}
instances:                             # O  physical units that were imaged or scanned
  - {instance_id: inst_000123_01, lot: lot_7731, condition: new, asset_ids: [img_000123_front, mesh_000123]}
text:
  - {field: description, language: en, license_ref: lic_R07_text}
provenance: {supplier_id: supplier_R07, extract_date: 2026-09-30, mapping_version: map_R07_v2}
rights:
  lic_R07_studio: {owner: supplier_R07, training: allowed, evaluation: allowed, redistribution: no}
  lic_R07_scan:   {owner: supplier_R07, training: allowed, evaluation: allowed, redistribution: no}
  lic_R07_text:   {owner: brand_0412, training: unconfirmed, evaluation: unconfirmed, redistribution: no}

Field groups and where they usually come from

Research object sets treat physical properties as fields of their own: the YCB set is distributed with scans, physical properties and geometric models (Calli et al., 2015). Commercial catalogs seldom do, which is why the physical group above defaults to unknown.

Parameters the buyer sets

Simulators need mass, inertia and friction, which are precisely the fields catalogs rarely hold. The schema therefore points to separate simulation assets (sim_refs) rather than pretending a catalog record is one; see simulation-ready object assets.

Acceptance tests

1. Schema validation. Every delivered record validates against the agreed schema version; rejected records are listed with the failing rule.
2. Referential integrity. Every asset reference resolves, every checksum matches, and every instance belongs to a product.
3. Null discipline. The share of unknown and not_applicable is reported per field; blank values fail.
4. Taxonomy validity. Each code exists in its stated release, and no GTIN carries two GPC bricks.
5. Provenance completeness. Every measurement carries a source class and a date; estimated values are flagged.
6. Plausibility and spot check. Density and range checks run on every record, and a random sample is measured physically against the listed values within your tolerance. The wider method is in the product master data quality audit.
7. Rights completeness. Every asset and text field has a license reference.

What a schema cannot do

A schema does not create data the source never held. A field filled by inference from a category is an estimate, and it should stay flagged as one. Structured attributes also describe objects at rest: no combination of dimensions, materials and flags shows how a bag sags, a lid sticks or a part slips, which is the line drawn in object recognition data vs manipulation training data. And a schema does not settle who may license a photograph; that remains a per-asset diligence question for product image rights.

Questions to ask suppliers

1. Which of these fields exist natively in your systems, and which would be derived at export?
2. Do you export one row per packaging level or one row per SKU?
3. How do you distinguish "unknown" from "not applicable" and from "not entered"?
4. Which taxonomy codes do you hold (GPC, UNSPSC, ACES/PIES, internal), and for which release?
5. Is every image or mesh linked to a product and packaging version by an identifier, and do you keep file checksums?
6. Can you export the source and date of each value?
7. Who owns each image and text field, and is that recorded per asset?
8. How do you handle packaging changes: new record, overwritten record or neither?

Discuss your requirements

If you want product data delivered to a schema like this, send SourceX your SKU scope, required groups and vocabularies. SourceX looks for US businesses that hold suitable product data, checks the data and the supplier's licensing permissions, and coordinates pricing, allowed uses and delivery in a license. Annotation to fill physical and handling fields is scoped case by case. SourceX reviews each request and follows up about potential sources; a request does not guarantee a match.

See also the product and object data hub, the product catalog data guide, the humanoid training data guide and the page on licensing product catalogs and descriptions.

Discuss your humanoid training-data requirements with SourceX

Sources

• GS1 Package and Product Measurement Standard (formerly GDSN Package Measurement Rules) — nominal measurement attributes and master-data sharing.
• ABO: Dataset and Benchmarks for Real-World 3D Object Understanding — metadata attributes and mesh coverage in catalog-derived data.
• GS1 Global Product Classification (GPC) — four-tier product classification with one brick per GTIN.
• Serial Shipping Container Code (SSCC) — identifier for logistic units such as cases and pallets.
• United Nations Standard Products and Services Code (UNSPSC) — open eight-digit classification across four levels.
• Auto Care Association ACES and PIES standards — aftermarket product information, fitment and asset hashing.
• glTF - Runtime 3D Asset Delivery — runtime 3D asset format with PBR materials.
• OpenUSD (Universal Scene Description) — schemas for geometry, shading, lighting and physics.
• MuJoCo — Advanced Physics Simulation (MJCF) — native XML model format.
• Benchmarking in Manipulation Research: The YCB Object and Model Set and Benchmarking Protocols — object sets distributed with physical properties.