A Reproducible Operating Method for Recording Robotics Dataset Provenance

Teams that maintain robotics datasets often discover too late that a download, a label set, and a robot-type taxonomy have drifted apart. A practical fix is to treat every dataset intake as a small reproducible experiment. The operating method below records inputs, observations, exceptions and a named owner at each step, so another engineer can repeat the same intake next quarter and see whether a change reflects the physical world or merely a change in description. The vocabulary used here follows the W3C Data Catalog Vocabulary (DCAT) Version 3 model of describing datasets in catalogs, while the robot-type framing follows the ISO 8373:2021 definition of an industrial robot summarized by the International Federation of Robotics.

Step 1: Register the intake inputs before touching any file

The owner for this step is the data steward. Inputs include the catalog record identifier, the distribution location, the declared media type, and the checksum if one was supplied. Under DCAT 3, a distribution can carry a checksum expressed with the SPDX vocabulary, which turns "we downloaded something" into a verifiable input. The observation recorded is the exact byte size, retrieval timestamp and checksum observed locally. An exception is logged if the local checksum differs from the catalog value, or if the catalog omits a checksum entirely; in that case the owner writes "checksum missing, unverified" rather than silently proceeding. Related robot-type context, such as whether the records concern articulated or SCARA platforms in the IFR classification, is entered as a free-text scope note so later readers know which mechanical structures the data are supposed to cover. Teams comparing sources often keep a separate note on robot type taxonomies to avoid mixing incompatible structures.

Step 2: Decode the declared robot scope against IFR categories

Using the IFR summary of ISO 8373:2021, the intake form asks the owner to mark the mechanical structures present in the dataset: Cartesian, SCARA, articulated, parallel/Delta, cylindrical or polar. This is not a guess; the observation field quotes the dataset's own documentation. If the documentation says only "industrial manipulator," the exception is "scope under-specified: no mechanical structure named," and the owner must request clarification or mark the record provisional. A practical benefit appears when a later revision of the dataset adds Cartesian gantry sessions to a previously articulated-only collection. Because the original scope was recorded, the change is visible as a method change rather than a hidden expansion of the sample. Readers who need the full mechanical breakdown can consult a structured robot type listing maintained alongside the glossary.

Step 3: Record observations about labels and session grouping

Input is the label schema file and the session manifest. The observation records how many sessions exist, whether sessions from the same physical run are kept together, and whether labels are direct observations or proxies. Direct observations are recorded as such; proxies are flagged with the proxy variable's name. An exception arises when two reviewers disagree on a label and the dataset provides no arbitration rule; the owner writes the disagreement count and defers resolution. This step matters because robot vision splits and label provenance are easy to confuse. Linking the intake note to session grouping guidance helps the next operator preserve related sessions instead of scattering them across train and test partitions by accident.

Step 4: Log exceptions and owner decisions in a single ledger

Every exception from the previous steps is appended to one ledger row per dataset version, with the owner's name and the date of decision. The ledger does not hide unresolved exceptions; it shows them as open items with a named responsible person. For example, if a checksum mismatch is later explained by a re-packaged archive, the owner records "mismatch resolved: repackaging confirmed by publisher on DATE; new checksum X accepted." The DCAT 3 versioning properties such as dcat:previousVersion and dcat:hasCurrentVersion are useful here because they let the ledger point backward and forward without rewriting history. A hypothetical example: suppose a warehouse mobile manipulator dataset changes its distribution URL after a catalog migration; the ledger would mark the old distribution as previousVersion and the new one as the current version, with the owner noting that no sensor content changed. That hypothetical example is labelled hypothetical, so it is not presented as a real incident.

Step 5: Reproduce the intake with a second operator

The reproducibility test requires a second owner to repeat steps one through four using the ledger alone, without asking the first operator questions. Inputs are the ledger row and the catalog record. The observation is whether the second operator arrives at the same scope marks, the same exception list and the same owner decisions. An exception is recorded when the second operator cannot reproduce a decision because the ledger used an ambiguous term such as "standard robot" instead of an IFR category. At that point the first owner revises the wording, and the ledger shows a small method correction. This step prevents the common failure where only the original collector understands their own notes.

Step 6: Publish the method record as a catalog entry supplement

The final output is a short machine-readable supplement attached to the catalog entry, using terms consistent with DCAT 3 so that external aggregators can consume it. The supplement states the dataset series if applicable, the version chain, the checksum, the observed robot-type scope, the label exceptions and the two owner names involved in intake and reproduction. By keeping this supplement next to the download rather than in a private spreadsheet, the dataset stops being an opaque file and becomes a described asset. The practical effect is that a later user asking whether a rise in recorded cycle-time variation reflects a market change or a labeling change can read the ledger and see which method change occurred, instead of assuming the physical process moved. In this way the operating method turns provenance from an afterthought into a repeatable record that survives staff turnover and catalog migrations.