A robotics market spreadsheet rarely fails because a number is wrong by one digit; it fails because a blank cell silently becomes a zero. When an analyst sorts deployment counts by integrator, region, or robot class, every empty row that should mean "we did not collect this" is read by the charting tool as "there is nothing here." In a market dataset covering warehouse AMRs, inspection drones, or collaborative arms, that confusion turns a coverage gap into a false floor of demand. The remedy is not to guess a value, but to record observation status explicitly and to treat genuine zeros as one narrow case among several distinct non-values.
DCAT 3 describes datasets in a broad and inclusive way, because data "comes in many forms including numbers, text, pixels, imagery, sound and other multi-media, and potentially other types, any of which might be collected into a dataset" (see Data Catalog Vocabulary (DCAT) - Version 3). A robotics spreadsheet is itself such a dataset, even when it is only a CSV or a tabular export. The vocabulary does not assume a particular serialization format and distinguishes the abstract dataset from its distributions, so a market table and its downloadable file can both be described without pretending that the file's internal blanks carry statistical meaning. When a cell is empty in the distribution, nothing in the vocabulary forces it to be a zero; the zero interpretation is added later by whoever builds the chart, not by the standard.
That later addition is the problem. A regional sales sheet for logistics robots may contain rows where a country was never surveyed, rows where a vendor suppressed the figure for competitive reasons, rows where the metric was not applicable because no service contract exists, and rows where the true value really is no units shipped. Those are four different situations. Only the last one belongs next to another numeric zero in a time series. Treating the first three as zero is not a data-cleaning shortcut; it is a change in what the dataset claims.
A useful documentation practice is to split absence into named states rather than leaving the reason implicit. An "unknown" state covers cells where the collector did not obtain a figure during the observation window, for example a service-robot integrator that did not respond to a survey about installed base. A "suppressed" state covers figures that exist but were intentionally withheld by the source, such as a confidential unit count from a single large automotive plant. A "not collected" state covers fields that were deliberately outside the scope of a particular round, for instance a table that tracks unit shipments but not annual maintenance revenue for every vendor. Finally, a genuine "zero" state records that the observation was made and the quantity was nil, such as verified no deployments in a specified quarter for a defined robot class.
Each of those states behaves differently in aggregation. Unknown and not-collected rows should normally be excluded from a sum rather than added as nothing. Suppressed rows should be flagged so a reviewer knows the total is a lower bound, not a complete count. Only genuine zero participates in arithmetic the same way a positive integer does. If a market dataset mixes them without a status column, any average, share, or growth rate computed downstream inherits an error that no later chart annotation can fully repair.
The PROV model gives a way to describe how entities such as datasets, charts, and tables came to exist and how their attributes changed, through activities, usage, and generation (see PROV Model Primer). In provenance terms, a spreadsheet cell is part of an entity whose state was produced by an activity: a collection round, an import script, or a manual correction. When that activity did not generate a numeric value, the absence itself has provenance. The primer explains that activities generate new entities and use existing ones, and that an agent may be associated with an activity and bear responsibility for it. That structure maps cleanly onto robotics market work: the analyst, the survey tool, and the vendor contact are all agents associated with the activity that either filled or did not fill a cell.
A recommended documentation practice is therefore to keep a provenance note beside the status field. For each row and each observation period, the record can state who performed the collection, what tool produced the import, and why the value is absent. If a figure is suppressed, the note can say so without publishing the number. If a field was not collected in that round, the note prevents a future user from assuming the vendor had zero revenue. PROV also distinguishes object-centered provenance, tracing parts of a document to their origins, which supports linking a chart back to the exact table version and the exact cell status used. The institutional specification is a modeling reference for this checklist, not an endorsement of any particular robotics vendor or market estimate.
The most practical fix inside a spreadsheet is a small controlled vocabulary in its own column. Rather than one free-text comment per row, use a single status value such as observed_zero, unknown, suppressed, or not_collected, plus an optional reason code. The numeric column itself can remain empty for every non-zero state, while the status column carries the meaning. This keeps sorting and filtering honest: a pivot table can exclude unknown rows from a denominator, and the genuine zeros remain visible as real observations.
A second column for the observation window is equally important. Robotics markets are often reported by quarter, by exhibition season, or by fiscal year, and a nil result for one window does not imply nil for another. Combining status with period prevents the classic error where a vendor with two quarters of no shipments is charted as if it had permanently exited the segment.
Consider a hypothetical example used only to illustrate the method. Suppose a tracker records quarterly unit counts for inspection robots across five industrial parks. In Q1, park A was surveyed and reported four units, so the value is 4. Park B was surveyed and reported no units installed that quarter, so the value is 0 with status observed_zero. Park C did not respond, so the numeric cell is empty and the status is unknown. Park D provided a figure but asked that it not be published individually, so the status is suppressed; because that known value is withheld, any published total excluding it is labeled a lower-bound partial aggregate. Park E was outside the survey scope for maintenance revenue that quarter, so the revenue cell is empty with status not_collected, even though the unit count for park E exists.
If all five unit-count rows were pasted into a chart without status, the software could draw park B at zero and leave parks C and D either blank or zero depending on settings; park E's separate revenue absence would need to remain distinct from its unit observation. A careless published story could then say inspection-robot demand fell to near zero across the portfolio, when in fact one park truly had nil installations and the other absences had different causes. The hypothetical example shows why the status column, not the numeric cell alone, is the unit of meaning.
Charts must respect the status field rather than flatten it. For genuine zeros, a plotted point at the axis with a clear marker is appropriate, because the observation exists. For unknown and not-collected rows, the recommended documentation practice is to break the line, omit the point, or use a visibly different gap marker, and to state in the caption that missing segments are not zero. For suppressed rows, the safest treatment is to exclude the point from the plotted series while annotating the axis or the accompanying table to show that one or more known values were withheld.
Legend text should also avoid saying "no data" when the real condition is "known value suppressed." Those phrases have different implications for a robotics market reader trying to judge whether a segment is dormant or merely unreported. Axis labels can carry a note such as "unknown quarters excluded from trend," which keeps the visual honest without inventing a number. Because PROV describes entities, activities, and agents across versions, a chart can also be linked to the specific dataset version and status codes used to produce it, so later corrections are traceable rather than overwritten silently.
Start by adding the status column before any new collection round, because retrofitting reasons onto old blanks is harder than recording them at the time. Use only the controlled values defined above, and require a short reason code when the value is not observed_zero. Keep the numeric column empty for every non-observed state so no chart can silently coerce a blank into arithmetic. Record the observation window for every row, and keep a separate provenance note listing the collector agent, the tool or script, and whether the source suppressed a known figure.
When publishing, exclude unknown and not-collected rows from denominators and label partial totals explicitly as lower bounds when suppression occurred. In every chart caption, distinguish "genuine zero observed" from "unknown / suppressed / not collected," and never present an absent line as a flat demand line. Finally, version the table and the status vocabulary together, so a reader can reproduce which rows were excluded from a given market view. These steps are recommended documentation practice for robotics market tables, not requirements of DCAT or PROV: they make absence visible instead of letting a spreadsheet pretend that missing is zero.
For further equipment reading, browse related industry updates and technical reference articles alongside this practical note.