Separating Published Robot Data from Editorial Inference in Model Records

On robotdatabase.net, every robot model entry is expected to do more than list numbers. The site’s position as a catalogue of robot model data records means each field should let a reader distinguish a published fact from later interpretation. A published fact carries a clear origin, a date, a scope and a source. Editorial inference is what editors add when they explain what those facts may mean for selection, comparison or application. Keeping the two apart is what makes a model page usable for engineers, integrators and procurement staff who need to know whether they are reading a specification or a comment on it.

What Counts as a Published Fact in a Robot Record

A published fact is a statement that appears in a traceable source and can be quoted with its date and coverage. When we use the definition supplied by the International Federation of Robotics at https://ifr.org/industrial-robots, we are quoting a published classification rather than inventing one. The IFR text sets out that its use of “industrial robot” follows ISO 8373:2021: an automatically controlled, reprogrammable multipurpose manipulator programmable in three or more axes, either fixed in place or fixed to a mobile platform for automation in an industrial environment. That sentence is a fact with a date (the ISO reference year given in the source), a scope (the IFR’s adopted definition) and a source (the IFR page). On this site, such material belongs in a field that names the source, not in a paragraph that blends it with opinion.

Recording Date, Scope and Source Beside Each Value

The problem of mixed metadata is familiar outside robotics. The W3C’s Data Catalog Vocabulary, described at https://www.w3.org/TR/vocab-dcat-3/, was built so that catalogues can describe datasets and data services with a standard model and still be read by other catalogues. DCAT 3 became a W3C Recommendation on 22 August 2024 and keeps backward compatibility with DCAT 2 while adding features such as versioning properties. For robot data, the lesson is practical: a payload figure should say which document it came from, when that document was issued, and whether it covers one model revision or a whole family. Without those three anchors, a number is just a digit that later readers may mistake for an independent measurement.

Why Mechanical Structure Entries Need Source Separation

Robot type pages such as those for articulated structures, parallel or delta mechanisms and SCARA configurations show why separation matters. The IFR source lists mechanical classes: Cartesian robots with three prismatic joints forming a Cartesian coordinate system, SCARA robots with two parallel rotary joints, articulated robots with three or more rotary joints, parallel or delta robots with closed-loop links, cylindrical robots combining rotary and prismatic axes in a cylindrical coordinate system, and polar robots using two rotary and one prismatic joint in a polar coordinate system. Those are published classifications from the cited source. An editor may add that a delta form suits fast pick-and-place work, but that added sentence is inference and should sit apart from the quoted structural definition so nobody cites the IFR for a performance claim it did not make.

Payload, Reach and Axes Are Not the Same Kind of Statement

A model record will often show maximum payload, reach and number of controlled axes together. Each of those is a published fact only when the source and its date are attached. Suppose a manufacturer document from a given year states a wrist payload for a specific arm; that is a scoped fact. If an editor then writes that the robot is therefore suitable for a certain assembly cell, the second statement uses the fact but is not itself the fact. This site keeps the two in different fields or clearly marked prose. Existing titles in this column have already argued that a gripper’s weight, its force and the robot’s rated payload are different measurements; the same discipline applies here, because mixing a sourced value with an application guess makes later revision harder when the source updates.

Versioning and Model Revisions in a Data Record

The DCAT 3 vocabulary added properties for versioning, including dcat:version, dcat:previousVersion and dcat:hasCurrentVersion, and a DatasetSeries class for representing series of datasets. Robot catalogues face the same issue with model revisions. A hypothetical example may help: imagine a controller firmware change in 2026 alters the repeatability figure published in a datasheet, while the mechanical arm stays the same. A good record links the old value to the old datasheet and the new value to the new one, using a version note rather than silently overwriting the field. That is a hypothetical example for illustration only, not a claim about an actual product. It shows why the catalogue habits described by the W3C recommendation are useful even for a robot database that is not built in RDF.

Editing Practice: Quote First, Then Interpret

The working rule for this column is simple. Quote the published item with its date, scope and source in the record’s fact field, then place any editorial reading in separate prose that says it is inference. The IFR definition and the W3C vocabulary descriptions above are both used here only as sourced statements about classification and metadata practice. By keeping them separate from comment, robotdatabase.net lets a reader reuse the classification for their own comparison while still seeing what the editors think it implies. That method also protects the database when sources are revised, because the fact and the comment can be updated independently without confusing one for the other.