search

GSS-Cogs / family-trade

1 stars 2 forks source link

Create an example of a versioned cube or codelist #93

Open Robsteranium opened 4 years ago

Robsteranium commented 4 years ago

Migrated from Swirrl/cogs-issues/issues/166.

From the trade project proposal:

Several of the Use Cases relate to being aware of changes to data (in terms of the observations (2.4), method (2.5), or reference data (2.6)), being able to identify different versions (1.4) and being able to reconcile and translate between codelists (4.2 and 4.3).

Data versioning is a deep and complicated topic. We won’t propose to resolve this completely at this stage. Ultimately we’d need correspondence tables between versions to let people map data from one version to the next.

At this stage we can begin to explore this topic, however. We have some initial ideas for modelling revisions. We could look to create a data cube or codelist that demonstrates some of these techniques so that we can learn more about the requirements for expressing versions and working with them.

The next step would be for @ajtucker and @MartynBSpooner to review the ideas for modelling revisions.

We can then identify a candidate(s) for creating some data or reference data with versions to then explore the implications for e.g. other data or the UI.

JasonHowell commented 3 years ago

@ajtucker based on above comments , what are the clear next steps?

Robsteranium commented 3 years ago

We've also picked this up with the discussion on data dependencies - note that's about "versions" (generic change) instead of "revisions" (changing observation values).

I would still welcome feedback on the original proposals for observation revisions. A next step might be to identify one or more dataset which has revisions (I would guess anything with chained-measures ought to involve this) and try out the proposed models to see whether they capture the publishers' intent.

In parallel we ought to think about cube and codelist versions. We're working on a proposal for a dependency/ packaging tool which will likely involve a model for versions. Unless there are any further comments on the requirements then we don't need any further input just yet.