Guide
How to normalize bearing width fields across suppliers
A worked method for separating ring width, total width, height and component widths without losing the original source label, value and unit.
Width is one of the most frequently compared bearing dimensions and one of the easiest to get wrong in a merged catalog. Supplier exports use short labels such as “B”, “W”, “Width”, “T” or “H”, and the same label can describe different physical dimensions depending on the bearing type, the document it came from and the convention of whoever built the export.
This guide describes how to map those labels into distinct target fields without silently turning one dimension into another.
The problem with a global rule
The shortcut most pipelines start with is a lookup table: “B means width”. It works until the catalog contains more than one family.
Depending on the bearing type, a column labelled with the same letter can plausibly carry:
- Ring width: the width of an individual inner or outer ring.
- Total or assembled width: the overall width of a bearing whose rings or components differ in width, such as some tapered or double-row designs.
- Height: for thrust bearings, the dimension along the axis is often specified as a height rather than a width.
- Component widths: separate widths for a cone, cup, inner ring or outer ring, published as distinct values.
- Housing or unit width: for mounted units, a dimension of the housing rather than the bearing insert.
Manufacturers also differ in which letters they use for which dimension, and translations add another layer. A single string-to-field rule will merge values that should never be compared.
Target fields
Define separate target fields before mapping anything. A minimal set for width-like dimensions:
| Target field | Definition | Applies to (example rule) |
|---|---|---|
ring_width | Width of a ring where inner and outer rings share a width | Single-row radial families with equal ring widths |
inner_ring_width | Width of the inner ring or cone | Families publishing ring widths separately |
outer_ring_width | Width of the outer ring or cup | Families publishing ring widths separately |
total_width | Overall assembled width | Families where the assembled width differs from ring widths |
height | Axial dimension of a thrust bearing | Thrust families |
unit_width | Width of a mounted unit or housing | Mounted units, not the insert |
The applicability column matters as much as the definition. If a target field does not apply to a family, values should never be mapped into it, and blanks in it should be recorded as not_applicable.
Map by context, not by string
A mapping rule should name all of the context it depends on. In practice that is at least:
- Source. Which supplier file, manufacturer document or feed the value came from.
- Family. The bearing type of the row, resolved before dimensions are mapped.
- Raw label. The original header or table caption, exactly as written.
- Position or caption. For documents, the table and column where the value appears.
A rule then reads like: for source “Supplier file A”, family “demo-thrust”, raw label “B” maps to height. The same label from the same source in family “demo-radial” maps to ring_width. A label that appears in a family without a documented rule is not mapped at all; it is queued for review.
Preserve the original
Every normalized value should carry the evidence of where it came from. In the MyBearings draft record, each attribute holds one or more assertions with the raw label, raw value, unit, source and location.
Illustrative, synthetic values:
| Source | Family | Raw label | Raw value | Target field | Normalized value | Unit | Rule |
|---|---|---|---|---|---|---|---|
| Supplier file A | demo-radial | B | 15 | ring_width | 15 | mm | A/radial/B |
| Supplier file A | demo-thrust | B | 14 | height | 14 | mm | A/thrust/B |
| Supplier file B | demo-tapered | T | 21.5 | total_width | 21.5 | mm | B/tapered/T |
| Supplier file B | demo-tapered | B | 20 | inner_ring_width | 20 | mm | B/tapered/B |
| Supplier file C | demo-radial | Width (in) | 0.5906 | ring_width | 15.0 | mm | C/radial/width-in |
| Supplier file C | demo-unit | Width | 38 | (unmapped) | — | — | No rule: unit or insert? |
Notice the last row. “Width” on a mounted-unit row could be the unit or the insert. Without a documented rule, the honest output is an unmapped value in a review queue, not a guess.
Units
Unit conversion is a separate step from field mapping, and both should be recorded.
- Keep the raw unit as published. If the header says inches, store inches as the raw unit even if the target is millimetres.
- Convert with a documented factor and keep enough precision that the conversion can be reversed without drift. Round for display, not for storage.
- Treat a missing unit as a problem, not a default. A bare number in a column without a unit in the header should be flagged until the unit is established from the source.
Detecting mapping errors
A mapping mistake usually shows up as a pattern, not a single bad value. Useful checks:
- Dimensional plausibility within a family. If ring width exceeds outer diameter for many rows from one source, the column probably carries a different dimension or the columns are shifted.
- Cross-source disagreement concentrated in one label. When one supplier’s “B” disagrees with another source on many rows of one family, review the mapping before reviewing individual values.
- Values in non-applicable fields. A height value on a radial row means a rule fired where it should not.
These checks do not prove a value is right. They tell you where to look first.
Unresolved cases
Some values cannot be mapped with confidence. Keep them visible:
- Mark the target attribute
unknownorconflictingwith the raw assertion attached, rather than leaving it blank. - Record why it was not mapped, for example “label ambiguous for family” or “unit not stated”.
- Feed the decision back as a new rule once it is resolved, so the next import from the same source maps automatically.
Apply it
- Check your export for missing units, blank required fields and invalid numeric values with the local catalog checker.
- See how raw labels and assertions are represented in the draft bearing record schema.
- Read more about attribute normalization, or discuss your catalog if you have a width mapping problem across several suppliers.
Methodology article using synthetic examples only; it states no manufacturer specifications. Independent technical review: not yet assigned. Found an error? Tell us.
