Operating a Reproducible Robotics Dataset Record: Step-by-Step Inputs, Observations and Owners

Putting together a robotics market dataset is less about the final spreadsheet and more about the trail of decisions that produced it. On roboticsindustrydata.com we treat every published figure as the output of a repeatable operating method rather than a one-off extraction. This article sets out a practical step-by-step record that a data steward can run each cycle: what inputs enter the process, what observations are logged at each gate, which exceptions are raised, and who owns the record. The method below is written for English-language robotics market data work and uses two reference anchors: the International Federation of Robotics definition of an industrial robot and the W3C Data Catalog Vocabulary (DCAT) - Version 3 for describing the resulting catalog entry.

Step One: Fix the Unit of Observation Before Any Count

The first input is the definitional boundary. Before any annual installation number is placed in a table, the record must state that the unit being counted follows the IFR usage of “industrial robot” as an automatically controlled, reprogrammable multipurpose manipulator programmable in three or more axes, based on ISO 8373:2021. The observation logged here is the source text and the date the definition was checked; the exception flag fires if a proposed row describes a machine with fewer than three axes, a fixed automation device that is not reprogrammable, or a service robot outside the industrial environment scope. The owner is the taxonomy lead, who is responsible for confirming that every row in the sheet maps to that definition or is explicitly marked out of scope. In practice this means a column labelled “axis-count-verified” is filled for each robot type—Cartesian, SCARA, articulated, parallel/Delta, cylindrical or polar—because mechanical structure determines whether the three-axis threshold is met. A hypothetical example would be a two-axis gantry loader entered by mistake: it is labelled hypothetical/假设示例 and routed to an exceptions sheet rather than the main denominator.

Step Two: Capture the Inputs With Their Provenance

Once the unit is fixed, the second step records the raw inputs. For robotics installation data the typical inputs are the country-level annual installation tables supplied by a statistical department such as the IFR Statistical Department’s compilation for around 40 countries, broken down by application area, customer industry and robot type. The observation is not just the number but its packaging: the study name World Robotics - Industrial Robots, the reference year, and whether the figure is installations or operational stock. The exception condition arises when a contributor supplies a forecast or an index rather than an observed result; those are diverted to a separate forecast log and never merged into the observed installation sheet. The owner at this gate is the ingestion analyst, who attaches a provenance note to each input file. When the same input is later republished in a data catalog, the DCAT 3 vocabulary supplies the standard model: the input becomes a dcat:Dataset described in a catalog, with distributions carrying checksums so that a later reader can verify the exact bytes that entered the process.

Step Three: Normalise Types Against the Mechanical Classification

Industrial robots are not interchangeable units, and the third step records how each row is normalised against mechanical structure. The inputs often arrive with free-text type labels; the operator maps them to the IFR classification set—Cartesian (rectangular/gantry), SCARA, articulated with three or more rotary joints, parallel/Delta, cylindrical or polar. The observation is the mapped class plus a confidence marker; the exception is raised for a label that matches none of the six structures, for instance a legacy term for a custom cell. That row is held for taxonomy review rather than forced into the nearest bucket. The owner is the classification reviewer, who also cross-checks against internal type references such as robot type 14, robot type 25 and robot type 17 where our own catalog uses a stable local identifier for a mechanical family. Linking the external mechanical definition to an internal type page keeps the record navigable for a user who arrives from a different entry point.

Step Four: Record Observations at the Denominator Gate

After normalisation, the process reaches the gate that most often causes silent error: deciding what belongs in the denominator. The observation written here is the denominator rule actually used—for example “annual installations in country X for customer industry Y, all robot types within the IFR industrial definition.” The exception is triggered when a row is missing for a country-year and a contributor proposes writing zero; the rule on this site is that missing is not zero, so the cell stays blank and an exception record is created with the reason “no submission received.” The owner is the market-data editor, who signs off that the total published as a share or growth rate uses the same denominator as the numerator. Because the IFR statistical work separates applications and industries, the editor must also note whether a productivity or flexibility claim such as reshoring or batch-size response is an observed statistical field or an editorial inference; only the former enters the numeric record.

Step Five: Describe the Output With DCAT for Reuse

The fifth step converts the cleaned record into a publishable catalog entry. Using DCAT 3, the cleaned installation dataset is described as a dcat:Dataset within a catalog, with a title, a description of the coverage, and one or more distributions. Where the operator produces a revised version of the same dataset, DCAT 3 supplies dcat:version, dcat:previousVersion and dcat:hasCurrentVersion, so the history of the record is machine-readable; a hypothetical case would be a v1.1 issued after an exception batch is resolved, labelled hypothetical/假设示例. Where the dataset is one of a recurring annual series, the dcat:DatasetSeries class groups the yearly releases. The observation is the serialised metadata graph; the exception is any missing mandatory property such as a distribution access URL or a checksum, which blocks publication until supplied. The owner is the metadata publisher, who is also responsible for keeping backward compatibility where an older DCAT 2 deployment is still in use, since DCAT 3 preserves prior terms.

Step Six: Assign Continuous Ownership and Exception Closure

The final step is a standing register rather than a one-time action. Each cycle, the operating record names the owners from the previous five steps—taxonomy lead, ingestion analyst, classification reviewer, market-data editor and metadata publisher—and lists open exceptions with an owner and a due state. The observation at closure is the resolution note: a taxonomy exception is closed when the classification reviewer maps the row or confirms it is out of scope; a missing-data exception is closed when the national statistical contact responds or the sheet is archived as incomplete. The exception remains open if no owner accepts it, and open exceptions are surfaced in the catalog description so a downstream user is not misled into reading a partial series as complete. This step is what makes the method reproducible: a new analyst can rerun the cycle from step one because the inputs, the mechanical normalisation against the IFR definition and the six structures, the denominator rule, the DCAT description and the ownership chain are all written down in the same record rather than held in one person’s memory.