Provenance for an Activity that produces a new Distribution of an already-registered Dataset

Open
#52 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
python
Domain
data

Research direction

Start with the existing Dataset.activity_id and Distribution concepts, then examine the proposed optional activity link alongside the DCAT and PROV JSON-LD considerations. Done means agreeing on the representation, defining the boundary between a new Distribution and a derived Dataset, and documenting guidance for users.

Written by the indexing model from the issue text.

Description

architecture metadata priority: medium

Surfaced while working through a real FDS use case.

Context. Provenance is attached at the Dataset level (Dataset.activity_id → the Activity that produced it). Distributions have no activity link, and all distributions of a Dataset must be "scientifically interchangeable".

Problem. A real case is an Activity (e.g. a format conversion Zarr → HDF5, or a re-export to a new store) that produces a new Distribution of an existing Dataset — not a new Dataset. There is currently nowhere to record which Activity generated that Distribution, so that provenance is lost.

Considerations:

  • Add an optional activity_id / prov:wasGeneratedBy on Distribution?
  • Distinguish "same scientific content, different encoding/location" (→ new Distribution) from "derived data" (→ new Dataset with wasDerivedFrom, cf. internal #9). Where's the line, and how do we guide users?
  • How this projects into DCAT / PROV JSON-LD.

Migrated from the internal tracker, where it was #30, opened 2026-07-27.

Dominant language
Python
Stars
0
Forks
1
Avg merge
26m
Merged PRs (30d)
24

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ukaea/fds

All issues in ukaea/fds

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.