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.)

[kd-ods]

@codemacabre, in the spec we say "...the data presented to the tool [...] is presumed to have a time dimension (that is to show the properties of people, entities and relationships changing over a period of time) if: ...". We haven't discussed the expected behaviour of the tool and UI in cases where the data is found NOT to have a time dimension.

How about this: there are three possible UI states:

1) In cases where the data is found NOT to have a time dimension (whether the data is 0.2/0.3-like or 0.4-like), the UI has no time-control toolbar (as now).

2) In cases where the data is 0.2/0.3-like and has a time dimension, the UI has a time-control toolbar, consisting of:

• 'Date:' label
• A date value (latest statementDate of an object in the BODS array), timepoint T
• A disabled slider with the handle of the slider at the right end. (Or - if it is likely to be annoying for users to have an unusable slider, we could replace the disabled slider with a message in italics like: "(Latest state of the network.)"

The idea is to indicate that: there is a time dimension in the data; that the BO network visualised is that of the final state of the data; that the final state of the network existed at timepoint T.

3) In cases where the data is 0.4-like and has a time dimension, the UI has a time-control toolbar, consisting of:

• A 'Date:' label
• A date value (latest statementDate of an object in the BODS array), timepoint T
• A slider which can be used to alter the date value (between min and max values of T as specced above)
• (Possibly an 'Apply' button if necessary.)

[codemacabre]

In working on this, I've encountered a weird bug with the arrowheads:

I believe it's because of the Bezier curves from bezier.js, so disabling the library entirely and using CSS transform to offset the lines, it improves, but the arrowheads are still misaligned:

Two points:

1. We're currently using the SVGtoBeziers() function which is not recommended to be used.
2. I don't think the CSS approach (second image) is very robust, and may break with larger graphs.

There's still a fair bit of work to do on the changes-over-time, so ideally I'd leave this bug as a separate issue (which I'm aware we might not have time to get to) rather than try to solve now.

@kd-ods Are you happy for this approach, or should I continue to try to resolve it now, potentially extending the changes-over-time work?

[kd-ods]

Yes - I'm very happy for you to file this as a separate issue and leave it for now, @codemacabre.