openownership
Update BODS Visualiser to handle BODS JSON from Open Ownership Register where replacesStatements is used
Currently if you download or copy/paste BODS JSON data for certain entities from the Open Ownership Register into the BODS visualiser hosted on openownership.org and try to create a visualisation of the data, you receive an error message saying "Sorry, there was an error drawing your data. Is it valid BODS?".
Following work on https://github.com/openownership/register/issues/169, can we please check what corrections we need to make to the BODS JSON formatting for these entities to make sure it can be accepted by the BODS Visualiser?
@spacesnottabs and I spent some time debugging this today. @spacesnottabs has found the explanation for why some BODS JSON work whereas others don't, and why this can't be fixed in Register 2 using BODS 0.2. This ticket will be updated with the conclusions.
Documentation by @spacesnottabs of the issue mentioned above: bods-visualiser-issue.pdf
Will be raised to be looked at as part of https://github.com/orgs/openownership/projects/8/views/1
@StephenAbbott - I think we have some options here. The problem as stated is:
The issue occurs because the edges of the graph (i.e the ownership or control statements) are not always republished or replaced when one of the statements is replaced.
This means that the edge could still refer to a replaced statement.
Strictly speaking, this is a problem on the mapping/register side. The main problem with replacesStatements is that it DOES mean that the edges should be republished/replaced when entity and person statements are replaced.
So this would be better fixed at the register/mapping end.
BUT we know replacesStatements is problematic. Hence the 0.4 proposals. So, we have the option of sitting with these inconvenient difficulties with BODS 0.2, the register mapping and the visualiser parsing problem. Then we can focus on moving to publish and handle BODS 0.4 and can highlight how this makes data handling easier.
To summarise, we have three options:
- Introduce a 'fix' to the Visualiser (which is actually a workaround to handle a not-great implementation of replacesStatements)
- Fix the not-great implementation of replacesStatements in the register BODS 0.2 data
- Leave the Visualiser unable to handle register BODS 0.2 data, as an example of why we are moving away from replacesStatements.
Strictly speaking, this is a problem on the mapping/register side. The main problem with replacesStatements is that it DOES mean that the edges should be republished/replaced when entity and person statements are replaced.
This surprised me, @kd-ods . Is this detailed in the BODS 0.2 spec somewhere so I can (re)read it? My understanding of the situation was that BODS 0.2 leaves this undefined or at least ambiguous, and that not all graph edge statements are necessarily replaced. Hence indeed the BODS 0.4 proposals, as you mention. But to say that the issue lies register/mapping end implies to me that BODS 0.2 in fact says that every one of the graph edges should be republished, always—leading to a storm of republishing every time something is changed.
No, you're quite right @tiredpixel - it was not ever set out very explicitly in the docs... imo, because the "storm of republishing" problem became apparent and doubling down on the replacesStatements implementation would not be helpful.
So when I say the 'problem' is on the register/mapping side, I should have said, that a different implementation on the register side would also deal with this issue.
But my general point is: replacesStatements is not a good BODS feature so we should be reluctant to spend time supporting it.
I'll need to consider the three options set out by @kd-ods:
- Introduce a 'fix' to the Visualiser (which is actually a workaround to handle a not-great implementation of replacesStatements)
- Fix the not-great implementation of replacesStatements in the register BODS 0.2 data
- Leave the Visualiser unable to handle register BODS 0.2 data, as an example of why we are moving away from replacesStatements.
Noting here that whichever option we go for, we need to document how the visualiser handles datasets with a historical dimension. There is a related ticket here: https://github.com/openownership/visualisation-tool/issues/141