Sample assets ship incorrect semantic labels and a deprecated SemanticsAPI block (nvbug 5945197)

Summary

The sample assets ship incorrect semantic labels, and ship a deprecated SemanticsAPI block alongside the current one. This was originally reported in nvbug 5945197; I re-verified it against the currently shipped binary .usd assets (not just the ASCII sources) on main (2026.04.1), so the file/line evidence below reflects what consumers actually download.

Note: the primary asset files are binary USD crate, so a plain grep over the repo finds nothing. The evidence below was produced by piping each asset through usdcat. (Shipping these as ASCII would make this directly greppable — filed separately.)

Problem 1 — semantics:labels:wikidata_class is the placeholder key string, not the class name

Across the props + packaging samples, the Wikidata class label is the literal metadata-key string "wikidata_qcode" instead of the object's class. For example, apple_a01/simready_usd/sm_apple_a01_01.usd:

token[] semantics:labels:wikidata_class = ["wikidata_qcode"]   # should be ["apple"]
token[] semantics:labels:wikidata_qcode = ["Q89"]              # Q-code is correct

Every apple/orange/coffee-cup/lamp/etc. asset therefore claims its class is the string "wikidata_qcode", which is meaningless to any downstream perception/training consumer.

Scope: 28 shipped files contain the broken placeholder. Affected assets (each in simready_usd + simready_physx_usd unless noted):

• alcohol_a01, apple_a01, coffee_cup_grasp_a01, gen_cleaning_dishwand_v01_01, obs_electricians_large_tool_box_a01, obs_joystick_a01, obs_lamp_revolute_a01, obs_orange_a01, obs_small_sledge_hammer_a01, obs_workbench_tool_a01
• coffee_cup_grasp_a01/isaac_usd/payloads/sample_coffee_cup_grasp_meshes.usd
• 5 packaging copies of apple/orange under packaging/simple_packages/**

Mixed: gen_appliance_toaster_v01_01 — root prim is correct (["toaster"]) but its 5 child prims are still ["wikidata_qcode"] (lines 336, 493, 557, 619, 680). The fix updated the top-level label but didn't propagate to part-level labels.

Correct counter-example: obs_light_bulb_01 ships ["light bulb"] / ["Q1318740"] — proof the correct shape is achievable; most assets just weren't re-exported through whatever path produced it.

Problem 2 — deprecated SemanticsAPI block still ships alongside the new API

Every asset that has any semantics applies both the new SemanticsLabelsAPI:* and the old SemanticsAPI:* schemas, e.g. apple_a01/.../sm_apple_a01_01.usd:

prepend apiSchemas = ["SemanticsLabelsAPI:wikidata_class", "SemanticsAPI:wikidata_class", ...]

custom string semantic:wikidata_class:params:query        = "apple"            # correct
custom string semantic:wikidata_class:params:semanticData = "wikidata_qcode"   # broken — should be "apple"
custom string semantic:wikidata_class:params:semanticType = "wikidata_class"
token[] semantics:labels:wikidata_class = ["wikidata_qcode"]

Two parallel semantic APIs ship in the same asset. Where they disagree (most assets today), behavior depends on which API the consumer happens to read. In the old block, query holds the right value but semanticData — the slot the SemanticsAPI consumer actually reads — is the placeholder.

Scope: 30 shipped files still carry the semantic:*:params block. This includes even the two correct obs_light_bulb_01 files: their values were repaired in both APIs, but the deprecated block was never removed — so zero assets pass "deprecate the old API."

Suggested resolution

1. Set semantics:labels:wikidata_class to the human-readable class name on every prim (root and children), matching the obs_light_bulb_01 shape.
2. Drop the deprecated SemanticsAPI:* / semantic:*:params schemas and properties; ship only SemanticsLabelsAPI.
3. Re-export all props + packaging through whatever path produced obs_light_bulb_01.
4. Decide whether robots should carry semantic labels — they currently carry none (separate from this issue, noted for completeness).
5. Consider a CI check in the conformance/validation suite that fails on ["wikidata_qcode"] and on presence of the deprecated block.

How to verify (works against the shipped binary assets)

# From sample_content/ — usdcat each asset, since the files are binary crate
find . \( -name '*.usd' -o -name '*.usda' \) -not -path '*/.thumbs/*' \
  -not -path '*/dcc_source/*' -not -path '*/temp/*' | while read -r f; do
    usdcat "$f" 2>/dev/null | grep -q 'wikidata_class = \["wikidata_qcode"\]' && echo "BROKEN LABEL: $f"
    usdcat "$f" 2>/dev/null | grep -q 'semantic:wikidata_class:params'        && echo "OLD API:      $f"
done

Verified on main @ 2026.04.1 (HEAD a1e9dd6), 2026-05-28: 28 files with the broken label, 30 with the deprecated block. Originating report: nvbug 5945197.

Start in sample_content/ with the provided usdcat verification loop, using the listed affected assets and the obs_light_bulb_01 files as the comparison case. Trace the asset re-export path that produced the shipped binary USD files and inspect any conformance or validation suite mentioned by the issue. Done means all shipped prims have the intended class labels and no deprecated semantic:*:params blocks remain.