Consider how the visualiser handles a beneficial ownership network changing over a period of time

[kd-ods]

Current situation

At the moment, all data is rendered according to the specification here.

No account is taken of fields like Interest.endDate, replacesStatements or field values like Interest.share.exact: 0 which indicate that information has changed over time, or that an interest is NOT present at a given time.

This means that when data represents change over time, it will either not be parsed (see this OO Register/visualiser issue) or it may be visualised in a confusing way: it may look like a snapshot in time, but actually historical information is layered over current information.

With BODS 0.4 there will be clearer requirements regarding how to represent changing beneficial ownership over time.

What to do

We need to consider how the visualiser should handle data that represents change over time, both in BODS 0.4 and prior versions of the standard.

The minimal requirements is probably: have the visualiser explicitly represent information at a given point of time.

[kd-ods]

Actually, I'm not sure that my assumptions above about the current situation are right. This code is using information from the replacesStatements field.

@codemacabre - When you have some time to investigate... could you let us know how the visualiser currently handles changing information about the same node/edge?

(This will help inform the decision regarding OO Register data not rendering in the visualiser.)

[kd-ods]

@codemacabre - I think we need to write out a description here of how to extract 'active' network information at date X from a BODS 0.4 dataset. To act as a specification. Do you want to have a crack at that? Or I can do it this week sometime.

[kd-ods]

The specification is on page 2 here

[kd-ods]

Beyond what's in the specification, we need to decide how the user of the tool inputs a time, T. The minimum and maximum possible values of T will be a function of the data inputed. I think we can simply say that for BODS 0.4-like data, we use the minimum and maximum values of statementDate.

I'm not sure how a date-picker would handle minimum and maximum possible values. It may be more elegant and user-friendly to use a slider. (And poss an 'apply' button, depending on how redraw works and how fast it happens.) The 'resolution' of the slider steps needs to be considered too.

(We also need to consider what happens with pre-0.4 data GUI-wise. For example we could just grey out the slider, with the slider handle to the far right.)