Separating Published Facts from Editorial Inference in Robot Maintenance Logs

On a maintenance case record platform, each entry about a robot service event should distinguish what was actually published as a fact from what an editor later interprets. A published fact includes a specific observation, the date it was recorded, the scope of equipment or components covered, and the source from which it came. Editorial inference goes further: it suggests causes, predicts recurrence, or generalizes across cases. Keeping these two layers separate lets later readers audit the record without confusing measurement with opinion.

Why a Fact Needs Its Own Date, Scope and Source

A maintenance log that says a gripper lost vacuum pressure is only useful if the reader knows when the reading was taken, which robot cell and tooling were involved, and whether the value came from a controller log, a technician’s handwritten note, or a sensor export. The PROV Model Primer describes provenance as descriptions of entities, people and processes involved in producing a piece of data or thing in the world. In our context, the entity is the robot or its subsystem, the activity is the inspection or repair action, and the record itself is influenced by whoever captured it. Without attaching date, scope and source to the observed value, the entry cannot be verified or reused in later analysis.

Recording the Activity Behind the Observation

An activity such as a scheduled inspection generates usage of tools and generation of a new record. The primer explains fundamental concepts including entities, activities, usage and generation, agents and responsibility, and time. When a technician replaces a seal and writes down the part number, the activity of replacement and the generation of the note should both be visible. A later editor may add a comment that the seal type is prone to wear in that environment; that comment is inference, not the original generated data. On /type/14.html we keep inspection records so the activity trail stays attached to the hardware history.

Agents and Their Responsibility in the Record

Provenance also covers agents and responsibility. The person or team that performed the work, the software that exported a log, and the editor who later annotated the case each have a role. If a service company uploads a repair sheet and our platform republishes it with a summary, the agent who authored the sheet and the agent who wrote the summary are different. The PROV view lets a record show that a value was attributed to a field engineer while an interpretation was attributed to an in-house reviewer. This separation is what makes a case defensible when someone asks why a conclusion was drawn.

Describing the Dataset and Its Distribution

When many case records are grouped, they form a catalog entry rather than a single note. The Data Catalog Vocabulary (DCAT) - Version 3 is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web. DCAT enables a publisher to describe datasets and data services in a catalog using a standard model and vocabulary. For our maintenance records, the dataset might be all vacuum-gripper cases in a quarter, described with a title, a time coverage and a distribution that others can pull. DCAT 3 also adds properties for supporting versioning, so a revised case set can point to its previous version without losing the older published facts.

Versioning and Series in Maintenance Case Sets

DCAT 3 introduces a version property and related links, plus a dataset series class for representing related collections over time. Suppose a quarterly export of oil-contamination cases is corrected after a mislabelled date is found; the new version can note the previous version while the original entries remain readable. On /type/25.html we maintain series views that let a reader move from one quarter’s set to the next without assuming later edits overwrote the first published scope. A hypothetical example would be a cell where three successive versions of a gripper case set show the same observed pressure drop but changing editorial notes about humidity; the facts stay stable while inference evolves.

Linking Back to Component-Level Histories

Finally, a single case does not stand alone. The same gripper model, controller firmware or energy-isolation step may appear across many entries. Internal links such as /type/17.html connect a maintenance fact to a component-level history without merging the observed data with someone’s summary of it. DCAT’s decentralized approach to publishing catalogs makes federated search possible, so a reader comparing cases across cells can see which parts of each entry are sourced facts and which are later interpretation. That discipline is what turns a pile of service notes into evidence a maintenance team can actually rely on.