An Updated Source Page Is Not Automatically a New Daily Story

The daily rhythm of robotics source tracking rewards fresh signals, but freshness alone is not news. A vendor or exhibition page can update its timestamp, rotate a banner, or republish the same paragraph with a new date while the underlying claims remain identical. For a newsroom that tracks "industry updates" every day, the risk is deduplication failure: an unchanged source page produces a new story, and readers see the same announcement wrapped as if it were new. The practical fix is not to distrust every update, but to separate three different things: when the page changed, what in the page changed, and whether that change is meaningful enough to become a story.

Timestamps Are Metadata, Not Evidence of New Content

An update timestamp tells a tracking desk that the resource was touched. It does not tell us whether a robot specification, exhibition date, or deployment claim changed. In the DCAT vocabulary, a catalog describes resources such as datasets, distributions, and data services, and supports describing versioning of resources; the catalog model distinguishes the abstract resource from its manifestations or distributions (Data Catalog Vocabulary (DCAT) - Version 3). That distinction matters for editorial work: the page we scrape can be treated as one manifestation, while the "story claim" we track can be mapped to the abstract resource description. A new build date on the HTML page is not necessarily a new version of the underlying announcement.

In practical terms, a source tracker should record the observed "last modified" value, the crawl time, and the URL used, then compare today's extracted text against yesterday's stored snapshot. If the diff is empty or only cosmetic, the honest output is "no material update," not a fresh article. This keeps the daily index clean and avoids the false impression that a robotics ecosystem is moving faster than it actually is.

Claim Diffs Beat Page Diffs

Raw HTML comparison is noisy because navigation menus, cookie notices, and dynamic widgets change constantly. A better unit of comparison is the set of normalized claims: exhibition city and month, product family, application scenario, organizer name, and any numeric capacity figure that the source actually states. When the claim set is unchanged, the page update is administrative. When one field changes—say a venue moves from one city to another, or a show month shifts—that is a genuine story seed.

A hypothetical example illustrates the method. Suppose a source page for a humanoid robot expo shows a 2026-10-27 timestamp today and showed 2026-10-26 yesterday, with identical text about "5月底开展" and "6万㎡" in Chinese or the English equivalent in translation. A claim diff would flag "date changed" but "claims unchanged," so the recommended documentation practice is to log it as a non-story update. By contrast, if the same page changes "December 2026" to "January 2027," the claim diff fires on the schedule field and the desk can write a real correction item.

Link Persistence and the Problem of Moving URLs

Daily tracking breaks when a source reorganizes its site and the old URL returns a redirect or a 404. DCAT's model makes the catalog, the cataloged resource, and the distribution separate parts of a description, with the RDF description covering the catalog itself and corresponding resources (Data Catalog Vocabulary (DCAT) - Version 3). For a newsroom that does not publish RDF, the transferable idea is simple: keep a stable internal identifier for the "source entity" separate from the volatile external URL. If the exhibition has a persistent internal slug, changing the external link does not create a new exhibition and should not create a new story.

Recommended practice is to store the canonical external URL, the date first seen, and the date last successfully resolved. If a URL fails, mark the source as degraded rather than silently substituting a new link and calling it "new." This protects the archive and prevents accidental duplication when the same event resurfaces under a different path.

Revision Notes Should Say What Actually Moved

A useful revision note in a source tracker states the changed field, the old value, the new value, and the reason the change is or is not story-worthy. "Page updated" is not a revision note. "Timestamp changed from 2026-10-26 to 2026-10-27; exhibition month unchanged at May; no new claim" is. Semantic Versioning offers a parallel discipline for software: once a versioned package has been released, the contents of that version must not be modified, and any modifications must be released as a new version, with MAJOR, MINOR, and PATCH increments carrying meaning (Semantic Versioning 2.0.0). Newsrooms can borrow the habit without claiming any standard requires it: a silent overwrite of yesterday's claim with today's claim, without a note, hides the diff.

The recommended documentation practice is to keep a small change ledger per tracked source. Each entry has a date, a field, an old value, a new value, and a disposition: "no story," "monitor," or "write." For robotics source tracking, most daily entries will be "no story," which is itself valuable information for editors deciding where to spend reporting time.

Why Version Thinking Helps Deduplication

Semantic Versioning defines that bug fixes not affecting the API increment the patch version, backward-compatible additions increment the minor, and incompatible API changes increment the major (Semantic Versioning 2.0.0). A tracking desk does not need to assign SemVer numbers to press releases, but the mental model transfers: a typo fix and a new product line are different magnitudes. If a robotics source page corrects a spelling of "Jazzy" or reformats a date, that is patch-level noise. If it adds a new downstream application track, that is a substantive addition. Treating both as "updated today" flattens meaning and floods the industry updates index.

Editors should also watch for the reverse error: assuming no visible change means no news when the change is actually in a linked sub-page or a data service rather than the main HTML. The safe observation is to record what was checked, not to guarantee that nothing changed elsewhere. This keeps the conclusion limited to the evidence actually collected.

A Practical Checklist for Daily Source Pages

The following checklist is a recommended documentation practice for daily tracking, not a requirement imposed by the cited vocabularies. Before publishing a story from a source-page update, confirm: the external URL resolves and is the expected entity; the internal source identifier matches the same exhibition, product family, or organization; the claim set was diffed against the previous snapshot; the changed field is substantive rather than cosmetic; a revision note records old and new values; and the disposition is explicitly "write," "monitor," or "no story." For longer analysis of tracking method rather than one-day items, the desk can route material to technical guides instead of the daily feed.

A second hypothetical example: suppose two different mirror pages both describe the same humanoid robot show, one with a 2026 date and one with 2027, and only the timestamp differs between crawls. The checklist forces the editor to ask whether these are two catalog entries for one event or two distinct resources. If the internal identifier and claims match, it is one story already covered. If the year truly differs, the diff on the year field is a real change. Either way, the decision is documented rather than guessed. On a robotics source-tracking site, the daily value comes from knowing what did not change as much as what did; an updated source page is not automatically a new daily story, and saying so plainly is better editorial hygiene than manufacturing novelty.