Version Lineage Graph¶
Lineage artifact — instantiates Carrier-Independent Work Identity Governance
Draws the family tree of a work — editions, releases, translations, branches, superseded versions, and the forks that became new works — so every instance's place in the line is visible.
A Version Lineage Graph is an artifact whose nodes are versions, editions, or instances of a work and whose edges are the relations among them — derived-from, superseded-by, translated-from, branched-into, forked-into-new-work. Its distinguishing move is to make those relations visible as a structure you can read at a glance, answering "where does this instance sit, what replaced it, and where did the line split into a different work?" — questions a flat list of versions simply can't. It is the one place the crucial distinction between a new version and a new work is drawn explicitly, as a typed edge.
Example¶
A dataset and its accompanying paper accumulate a tangle of instances: a preprint (v1, v2), the peer-reviewed version of record[n1], a corrected version after an erratum, three translations, and — after a methodological disagreement — a separate group's re-analysis that reused the data but reached different conclusions. Who cites what? Is the re-analysis "version 4" or a different work? The Version Lineage Graph lays it out: the preprints and version of record form one line, each superseding the last for citation purposes; the corrected version supersedes the version of record for reading; the translations hang off the expression they render; and the re-analysis is drawn as a fork — an edge that says "derived from, but a new work" — not another node in the main line. A reader landing on any node can trace up to the origin and across to what supersedes it, and can see at a glance that citing the re-analysis is not citing the original.
How it works¶
- Nodes are instances, edges are relations — every version, edition, translation, or branch is a node; every derivation, supersession, and fork is a typed edge.
- Type the edges — distinguish supersedes (same work, new preferred version) from forks (derived but now a separate work) from renders (a translation or format of an expression); the edge types carry the identity verdict.
- Mark supersession and replacement — flag which nodes are current, which are superseded (kept for provenance), and which are withdrawn or replaced, so consumers can find the right one.
- Trace both directions — support reading ancestry (where did this come from) and descent (what came after, what replaced it, where it split).
Tuning parameters¶
- Node granularity — every commit or draft versus only released, citable versions. Fine granularity is complete but noisy; coarse is readable but hides steps.
- Edge vocabulary — how many relation types (just "derived-from," or a rich set including supersedes / forks / translates / merges). Richer edges carry more identity information but demand discipline to apply consistently.
- Fork visibility — whether forks-into-new-works are shown in the same graph (context) or split into a separate one (clarity).
- Currency marking — how aggressively superseded nodes are de-emphasized versus preserved as first-class history.
- Automation — hand-curated versus generated from a version-control or repository system's events.
When it helps, and when it misleads¶
Its strength is that it turns a pile of versions into a legible structure and puts the version-versus-new-work distinction on the page as a typed edge, letting anyone locate the current, authoritative instance and see what a given node descends from.
Its failure modes come from the edges being drawn by hand. The graph is only as truthful as the relations someone recorded: an undrawn fork makes a separate work look like a mere version (borrowing authority it shouldn't), and a mislabeled supersession hides that the "latest" is actually a divergent branch. It records the topology but does not, by itself, justify each edge — whether a split is truly a fork is a judgment made elsewhere — and a large, tidy graph can imply more rigor than the messy history behind it ever had. The discipline is to source edges from actual events and recorded decisions rather than reconstructing them from memory, and to treat each fork/supersede label as a claim that a fork decision, not the graph, is responsible for.
How it implements the components¶
provenance_lineage_trace— the graph is the lineage trace: the readable record of what each instance descends from, all the way to the origin.supersession_and_replacement_rule— its typed edges mark which versions supersede or replace which, so the current instance and the superseded ones are unambiguous.
It renders the lineage but does not decide the fork threshold that produced a branch — that is the Fork Decision Record — nor capture each modification event with its metadata, which the Archival Provenance Metadata Template holds, and it does not formalize the work / expression / manifestation levels, which the Work–Expression–Manifestation Matrix does.
Related¶
- Instantiates: Carrier-Independent Work Identity Governance — makes the line of descent, and the split between version and new work, visible across all a work's instances.
- Consumes: the Fork Decision Record and Archival Provenance Metadata Template supply the fork verdicts and events the graph draws.
- Sibling mechanisms: Work–Expression–Manifestation Matrix · Persistent-Identifier Resolution Policy · Fork Decision Record · Archival Provenance Metadata Template · Edition and Manifestation Catalog
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Version Lineage Graph operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it draws the family tree of a work — editions, releases, translations, branches, superseded versions, and the forks that became new works — so every instance's place in the line is visible.
Independent corroboration: The frozen evidence defines Version Lineage Graph as 'Draws the family tree of a work — editions, releases, translations, branches, superseded versions, and the forks that became new works — so every instance's place in the line is visible', so its operative form is Representation, Specification & Plan.
Nearest alternative: Record, Log & Register — Version Lineage Graph includes features of a persistent ledger, log, register, or case record that preserves history and traceability, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Dublin Core Metadata Initiative, DCMI Metadata Terms documents that information science distinguishes versions, provenance, identifiers, spatial coverage, and relations so records remain interpretable through change. This is direct, mechanism-specific evidence for library information science as the best-evidenced historical home of the operation—Draws the family tree of a work — editions, releases, translations, branches, superseded versions, and the forks that became new works — so every instance's place in the line is visible.—rather than evidence merely that the operation is useful there. The retained alternates record genuine adjacent lineages; later portability is represented separately by domain_reach=universal.
Related originating lineages:
- Computer Science & Software Engineering — Computer Science supplies a historically relevant adjacent lineage or formative practice for the operation—Draws the family tree of a work — editions, releases, translations, branches, superseded versions, and the forks that became new works — so every instance's place in the line is visible.—but the adjudicated evidence more directly locates the defining lineage in library information science.
- Data Science & Analytics — Data science's modeling, validation, and monitoring tradition contributes a separate formative lineage to the mechanism's version lineage graph logic.
- History & Historiography — Historical and historiographic method supplies a parallel or contributing lineage for the mechanism's defining operation: draws the family tree of a work — editions, releases, translations, branches, superseded versions, and the forks that became new works — so every instance's place in the line is visible.
Review resolution: The blind reviewers disagree on primary lineage (computer_science versus library_information_science). The defining operation is: Draws the family tree of a work — editions, releases, translations, branches, superseded versions, and the forks that became new works — so every instance's place in the line is visible. The researched Dublin Core Metadata Initiative, DCMI Metadata Terms establishes that information science distinguishes versions, provenance, identifiers, spatial coverage, and relations so records remain interpretable through change. That source therefore supports library information science as the historical origin. computer science remains in the uncapped alternates where it contributes a formative practice, but application or governance is not itself proof of origin. origin_mode=single_lineage records lineage construction; domain_reach=universal separately records later applicability.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
The graph is descriptive, not authoritative: it should mirror decisions recorded elsewhere (fork records, supersession rules), never be the place those decisions are made. Once people start editing the graph to "declare" a fork, it has quietly become a governance instrument it was never validated to be — and the edge no longer traces back to any decision anyone is accountable for.
[n1] Version of record (VoR) — in scholarly publishing, the formally published, citable version of a work that the publisher maintains as authoritative, as distinct from preprints or author manuscripts. It is a concrete instance of a supersession rule: a corrected version can supersede the earlier one for reading while the line remains a single citable work. ↩