A Product Alias Is Not a New Robot Model

On a robot model database, the hardest record to maintain is often not the newest machine but the same machine sold under another name. A distributor may relabel a platform for a regional market, a system integrator may bundle it with a gripper and give the package a new part number, or a datasheet may be reissued as "revision B" with minor wording changes. None of those acts create a new robot model. They create an alias, a bundle, or a document version. Treating them as separate entities inflates the catalog, breaks cross-referencing, and makes long-term maintenance harder for editors who later try to reconcile duplicate entries.

Alias, Variant, and Bundle Are Different Record Types

A product alias is a naming layer: the same physical robot type appears in trade literature under a second commercial designation. A hypothetical example helps clarify the boundary. Suppose a manufacturer sells a six-axis arm as "Model TX-60" in one region, while a regional distributor lists the identical arm as "TX-60R" with a different paint color and a localized manual. For curation purposes, TX-60R is best recorded as an alias of the TX-60 entity, not as a new robot model row, unless a documented engineering change shows that it is a distinct model. A bundle is different again: if the distributor adds a vision kit and sells the package as "TX-60 Vision Package," the package is a configured system, while the base arm remains the original model. Keeping the base model stable allows the configured system to be linked to it rather than replacing it.

The distinction matters because a robot database is not only a list of names. It is a record of identifiable machine types and the documents that describe them. When an alias becomes a separate entry, the same serial-number range, payload class, and mounting pattern may be split across two pages, and a later editor comparing specifications cannot tell whether the difference reflects engineering change or merely branding.

Stable Identity Versus Document Versions

The DCAT vocabulary makes a useful conceptual separation for this problem. According to the W3C Data Catalog Vocabulary, a catalog distinguishes between a dataset as an abstract idea and a distribution as a manifestation of that dataset, and DCAT 3 also supports describing versioning of resources and cataloging dataset series alongside datasets and services DCAT 3. For a robot database, an analogous practice is to treat a robot model as the stable entity in the local catalog, while attaching datasheets, CAD packs, and marketing PDFs as separately versioned documents. This is only a loose analogy: DCAT distributions are accessible forms of datasets, not a defined representation of physical robot models.

A "revision B" datasheet is therefore not a new robot. It is a later version of the describing document. If the torque limits, reach, or repeatability values change in revision B, those may indicate either a real model update or only a correction of earlier published figures; the curation note should say which interpretation was used, rather than silently spawning a second model page. DCAT's own guidance does not prescribe a robot registry, so this is a database practice that borrows the vocabulary's structure without claiming the standard mandates it.

Provenance Explains How the Alias Appeared

The PROV Model Primer gives language for the other half of the problem: why a second name exists at all. PROV describes entities, activities, agents, and how entities come into existence or change through activities, with agents such as people, software, or organizations assigned responsibility for those activities PROV Model Primer. In catalog terms, a distributor relabeling activity is the event that produced the TX-60R designation, and the distributor organization is the agent associated with that activity.

Recommended documentation practice is to keep a provenance note in the alias record: who introduced the alternate name, in what market context, and from which source document the alias was observed. The note records that the alias was seen in a distributor catalog; it does not describe any change to the robot itself. If the alias later disappears from trade channels, the note preserves why the name once existed, which prevents a future editor from mistaking it for an unknown lost model.

Using Provenance Without Overclaiming Compliance

Because PROV is a model for provenance interchange on the web, the primer provides a reference for describing provenance records, not an endorsement of any particular robot checklist. The source explains that provenance records are metadata describing entities, activities, agents, and how things were produced or delivered PROV Model Primer. That supports our internal use of an "alias provenance" field. It does not mean a robot database must use full PROV Ontology serialization, nor that the reference requires any specific set of robot attributes.

Similarly, DCAT's classes such as catalog, resource, dataset, and distribution are described for data catalogs, and the specification says complementary vocabularies can be used together with DCAT for more detailed format-specific information DCAT 3. A robot model database can map its own entity pages onto that conceptual split without asserting that W3C prescribes a robot registry. The recommendation here is editorial: keep the model ID stable, attach documents as distributions, and tag aliases as naming variants.

An Original Curation Checklist for Alternate Names

A practical checklist for this workflow can be applied when a newly observed name might be an alias. First, compare the physical and performance fields: if payload, reach, axes, controller family, and mounting interface match an existing entry, treat the new name as an alias unless a verified change is documented. Second, check whether the new name refers to a package that includes added end-effectors or software; if so, record it as a configured system linked to the base model. Third, record the observing document and distributor in a provenance field. Where the relabeling is modeled as an activity associated with the distributor as an agent, PROV can represent those roles in the origin record PROV Model Primer.

Fourth, preserve the datasheet version history separately from the model identity. DCAT's distinction between an abstract dataset and its distributions can inform the organization of document records, but it does not itself define a robot-model versioning scheme DCAT 3. Fifth, use "hypothetical example" labeling when the alias scenario is invented for illustration, so a real distributor renaming is never confused with a constructed case. Sixth, avoid deleting the earlier name; deprecated aliases should remain searchable so that older industry updates referencing the former designation still resolve to one canonical model record.

Why This Supports Cleaner Technical Records

Alternate names are normal in robotics distribution, but they become noise when a database mistakes them for new engineering entities. By separating stable identity from naming variants, configured bundles, and document versions, a robot model data record stays useful for comparison and long-term maintenance. The approach also fits broader technical guides on curation: the goal is not to eliminate every commercial label, but to attach each label to the correct underlying machine type and to the document where it was observed.

For catalog editors, the practical outcome is fewer duplicate pages and clearer specifications. A search for either the original designation or the relabeled variant should land on the same robot model entry, with the alias history and provenance note visible. That keeps the database a record of machines rather than a mirror of every marketing PDF, and it preserves the evidence for why each name existed without making claims about certification, compliance, or field modification of the equipment itself.