openownership
Revisions to isComponent
If #317 is accepted, then some of the justification for isComponent is removed. This issue suggests further revision of isComponent to remove it from personStatement and entityStatement and to consider renaming it to parentStatement to highlight that it represents a hierarchical relationship between direct (child) and indirect (parent) relationships.
How does isComponent currently function
The purpose of isComponent is poorly explained in current documentation, but at least one of the motivations for it's presence appears to be _"the replacement of this [Component] Ownership-or-control Statement SHOULD be considered when replacing the primary Ownership-or-control Statement,".
The disclosureDetails approach to statement replacement removes the need for this.
This leaves isComponent as an explicit signal to consuming applications that some direct relationship between two entities is being disclosed because it is a component of an indirect relationship between some person and some entity.
The diagram below shows that, for the network:
(Source)
Using isComponent we would have one 'master' ownershipOrControl statement, and all the 'components' pointing to it with an isComponent relationship:
isComponent is primarily a relationship between ownershipOrControlStatements, but personStatement and entityStatement objects also currently have isComponent.
This implies that if multiple indirect relationships existed a single disclosure (e.g. Person 1 indirectly controls Company B by two different disclosable routes), the personStatement and entityStatement components of a relationship would have to be repeated. This is not desirable.
Outline proposal for changes
isComponent should be removed from personStatement and entityStatement.
The case for explicit fields to record the relationship between an indirect ownershipOrControlStatement and the direct ownershipOrControlStatements that make it up (wholly or partially) should be more clearly documented, with particular attention to:
- The workflows by which this data would be created
- How consuming applications may use this data
Consideration should be given to changing the isComponent relationship between ownershipOrControlStatements to become parentStatement because this more clearly articulates the idea that a direct statement exists in the dataset by virtue of disclosure of the indirect relationship.
Thanks for flagging this inconsistency @timgdavies - I think it's an interesting topic to revisit.
My thoughts so far:
This implies that if multiple indirect relationships existed a single disclosure (e.g. Person 1 indirectly controls Company B by two different disclosable routes), the personStatement and entityStatement components of a relationship would have to be repeated. This is not desirable.
In this case (within a single disclosure) wouldn't you have a single 'primary declaration of the relationship' containing the summarised ownership and control of all the different routes, then separate statements for all the components? I don't see how this could result in duplicating people/entities?
I think a lot of the explanatory guidance we need here is contained in the original proposal https://github.com/openownership/data-standard/issues/156. From that, the reasons for isComponent are given as:
- We know which other statements to replace when an indirect ownership statement is replaced;
- We can distinguish between canonical representations of relationships between subjects and interested parties, and representations that may only partially describe a relationship.
Thinking about 1. in light of #317, I'm more inclined to say that it's the publisher's responsibility to replace/null/end all the indirect statements when that happens. Why shouldn't they be expected to store these and (between them and the actual discloser) figure out which ones need to change when an update is made? Why does every single data user need to do that instead? In other words, I think replacesStatements could cover this use-case.
On 2. I'm in agreement that we can remove isComponent from entities and people, but if we take my view on 1. I don't think we need anything additional to do it. All isComponent does is make it explicit that intermediate relationships are part (but not the whole picture) of an how an ultimate ownership is manifest. Consuming systems do not need explicit markers on entities to make use of this information. (They could make use of Source.assertedBy for further information if needed).
I'd happily support a renaming (and note that originally we were discussing primary/secondary in #156).
To summarise, I think this needs evaluating in the context of our expectations of publishers/disclosers to make sense of updated data. My current feeling is that publishers need to provide good UIs for disclosers to assume the responsibility of not just saying how data is, but how it has changed. Pushing that responsibility anywhere else, and trying to provide data fields to enable it, is just adding more complexity.
Thanks @stevenday.
I don't see how this could result in duplicating people/entities?
You are correct: I've been reading the direction of the componentStatementIDs wrong. As componentStatementIDs is an array in the OwnershipOrControlStatement I've misidentified a problem. Editing above to strike that out.
To summarise, I think this needs evaluating in the context of our expectations of publishers/disclosers to make sense of updated data.
As on #317, I think I've got a different view overall on whether it's realistic to rely on publishers to replace/null/end all statements - but happy to keep exploring this to identify tests/evidence to support judgement call and/or write things up for wider consultation on the substantive question of which stakeholders should be bound by certain functional requirements.
If #317 is accepted, then some of the justification for isComponent is removed.
FWIW, the remainder of the justification for isComponent is stil substantial, so we can probably decouple consideration of #317 from consideration of changes to isComponent.
isComponent should be removed from personStatement and entityStatement. I was about to agree, but do we definitely want to remove from publishers the option to flag entities (and individuals) as intermediaries, and to force them to point to the component ooc statements? In some situations this could force them to create an ooc statement where it would't have been needed before (though its existence could have been inferred).
On the renaming question. I'm not sure that primary/secondary or parentStatement would work in situations where the 'child' statement would be disclosed regardless of whether it also contributed to a BO relationship. E.g. in disclosure regimes where all legal owners have to be disclosed.
The following idea has come up in conversation a few times. Here seems the best place to log it. We should consider renaming componentStatementIdIDs and isComponent to intermediaryStatementIDs and isIntermediary. This echoes language that has emerged in the Beneficial Ownership world.
(And I think we need to reserve judgement on whether to remove isComponent / isIntermediary from any statement types until our direction on change-over-time is clear.)
Following discussions about https://github.com/openownership/lib-cove-bods/issues/132 noting that the inclusion of 'isComponent' in person statements is effectively meaningless as there's no situation where a person would be a component of a larger relationship
