Implementation proposal: Representing declarations

[kd-ods]

Feature name

Representing declarations

Feature ticket

#463

Implementation proposal status

Active

Overview

The following two proposals seek to meet the requirements outlined in the feature ticket about Representing Declarations.

• Introduce an optional declarationReference field into each statement. The value of the field is an identifier for a declaration. Where a statement is an element of a particular declaration (made at a point in time by a declarant) this field should be used to identify the declaration.
• Introduce a required rootRecordReference field to all statement types. The value of the field is a recordId for a record representing the root subject of a beneficial ownership network (always an entity or person). The recordId will be that of the declarant in systems handling self-declared beneficial ownership information. (For more on recordIds, see the Changing Beneficial Ownership over time proposal.)

Detailed implementation proposal

The detail of the proposal can be found in this 4-page document

[kd-ods]

In reviewing the proposal, @rhiaro had some useful reflections on the naming of these two new properties.

On declarationReference: "I'd want to call this partOf or something, but I think it's just because I think exclusively in triples."

On rootRecordReference: "Assuming the field rootRecordId isn't used on the root record itself, this is actually what I'd want to call this field. But I understand that you're using 'reference' to mean the inverse of 'Id' so if that's the pattern it makes sense. I'm just nitpicking really, and have spent too much time looking at json-ld."

I agree that we should tighten up naming of fields like these (and make naming patterns consistent across the schema). One thing to note is that these two properties are different inasmuch as the value of declarationReference is not an ID of any object actually found in a BODS dataset. Whereas rootRecordReference will have a value which is an ID of a set of Record objects in a BODS dataset. So these are different types of references and could have different naming patterns.

Another thing is that the nature of rootRecordReference is similar to that of describedByEntityStatement and describedByPersonStatement in ownership-or-control statements. So it would be good if they used the same naming pattern. (A complicating factor being that those latter property names are going to need to change and be restructured anyway.)

So, I'd be happy to change declarationReference to partOfDeclaration. I'm less sure about the naming pattern we should use for the second type of reference.

[kd-ods]

Thinking about this alongside #467, I currently think that the fields should be called:

• partOfDeclaration
• rootRecord

And the recordReference object from #467 could have the fields:

• record
• recordType

[kd-ods]

Following in-person discussions, we've settled on the following property names, instead of those above:

• declaration
• declarantRecord

(The record reference object from #467 can still have record and recordType properties.)

[jpmckinney]

Discussion has focused on naming, but I’d like to take a step back and focus on purpose. (Sidenote: I can’t figure out when to comment on features vs proposals - I’m used to proposals just being part of feature discussions.)

(1) Are declarations predictable?

For example, would it be the case that some registries only contain self-declarations, such that this part of the model is just faff? In other words, would we be making explicit something that could just as well be implicit? A good standard needs to be selective about what to include.

(2) Are the use cases real?

#463 describes use cases, but are these from real users (plural!) who experience these needs for real work - or are they imagined? I feel like sometimes BODS anticipates a much more complicated data environment than is realistic (all sorts of agents making statements, and not just companies submitting to authorities).

[kd-ods]

Thanks, @jpmckinney - these are useful reflections. I certainly agree that a good standard needs to be selective about what to include. (I'll pick that broader point up on another thread: I think we agree that a slimming down of BODS is in order.)

On (2): we're still working on a 'best guess' basis on many fronts given the nascent nature of beneficial ownership transparency. However - and back to (1) here - we do know that the concept of a 'declaration' is one that we see across all disclosure frameworks internationally. So - yes - most registries only contain self-declarations. The issue is that it is currently extremely difficult to identify which statements within BODS data are part of a single declaration (or from a single declarant). These new fields address that problem.

[jpmckinney]

Assuming a statement is always annotated with a date (not sure if this assumption holds), then in the case where all declarations are self-declarations, determining which statements are from which declaration just requires grouping by both date and entity (since the author of a self-declaration is the same as the entity the declaration describes, by definition).

This also assumes a company never makes multiple self-declarations on the same day (though if a publisher has a time component to the date, then this assumption isn't needed).

Perhaps I'm misunderstanding the problem, and you could describe the difficulty through an example?

Edit: The "this field" in the next comment refers to the declaration field.

[kd-ods]

This also assumes a company never makes multiple self-declarations on the same day (though if a publisher has a time component to the date, then this assumption isn't needed).

I think this is the issue. At the moment, we are seeing declaration systems that work in diverse ways. Multiple declarations can sometimes be made on the same day and we can't assume that a timestamp is stored. Where declaration systems do have an internal reference number/id for declarations we don't want that information to be lost, hence this field. (It won't be a required field.)

[kathryn-ods]

I've been making some test data for 0.4 and just based on the field name I assumed 'declarantRecord' referred to the person making the declaration, not the business that the declaration is being made about. I would always assume 'declarant' is referring to a person and others might make the same assumption.

'declarantBusinessRecord' or 'declarantEntityRecord' is a bit clunky but maybe clearer.

I think 'rootRecord' could also work but some people would need to look that up (which isn't necessarily a problem.)

[kd-ods]

There's some back-and-forth on the separating core and metadata proposal about careful choice of terms. It made me think about how this field might be more helpfully named as declarationSubject.

[kathryn-ods]

I like that as a solution!

[jpmckinney]

I agree that declarant is confusing (it was not defined in that other issue – it just appeared as a row in a spreadsheet). Like @kathryn-ods, I also didn't know how it overlapped with assertedBy.

I think here it might be simplest to turn declaration into an object (so that we can say more than one thing about a declaration without adding more properties with a declaration prefix), give it an id field (which is what declaration was doing) and give it an entity field (which can be defined as the declaring entity, with a second sentence describing that the declaration can be submitted by an agent, on behalf of the declaring entity – for further clarification).

As in that other issue and in my new comment in this discussion, I don't think "subject" is super clear unless you've spent a lot of time with BODS (and in that other issue I suggest replacing it). At any rate, if "subject" can be avoided in new fields, it might yield less confusion.

[tiredpixel]

I'm a bit new to this so might well be missing something obvious, but after reading #463 and #482 and the related discussion a few times, I still can't work out what the difference between a statement and a declaration is (perhaps not helped by them being loose synonyms). As far as I've got is a statement is something published by a source (e.g. UK Companies House), and a declaration is something made from an entity to that source (e.g. a mandatory 'declaration' of beneficial owners or controlling interests). (I'm not sure about how something like any details submitted in a Corporate Tax Return would be modelled, here…)

But statement can of course be person or entity or ownership-or-control, in which case, how is a declaration different to an ownership-or-control statement? If it's because it's self-declared, introducing a different type just to capture that seems a bit odd to me. Do we 'trust' ownership-or-control statements—by which I mean, is there something authoritative about them which wouldn't be acceptable for an entity to submit to a corporate register or similar? And multiple ownership-or-control statements between entities possible—e.g. one self-declared, one analysed from a third-party source, and one deduced by exploring the network graph? Is a declaration a new type of statement, or a new type altogether?

However, looking through the BODS 0.4 - Declaration proposal document, it appears to be that a declaration is just a group of statements—not my attempt above at understanding at all! Since the proposed fields would be optional, a statement would not necessarily be part of a declaration. So what is the type of data which would lend itself to using this grouping? I note @jpmckinney's observation that it's possible to just group by both date and entity—this makes good sense to me…. Personally, I think considerations regarding granularity of statement dates or multiple statements per day are a separate topic—I'm not sure how declarations would resolve this especially given as the fields would be optional…

So I'm rather confused. Are there some simple examples I can read somewhere, in order to understand this better?

[jpmckinney]

In a paper-based process, my understanding is that a declaration is the form that a declarant fills out and submits. This declaration contains one or more statements (a statement being an invention of BODS to model the granular facts in a declaration).

[tiredpixel]

Thanks, @jpmckinney. So the new declaration would be an optional grouping for statement, nothing more? i.e. a 'statement-group', if you will.

[kd-ods]

So the new declaration would be an optional grouping for statement, nothing more?

Yes.

[tiredpixel]

Okay, that makes more sense to me. Thank you both for your time in explaining.

[jpmckinney]

I would recommend finding another word than "root". Beneficial ownership networks do not have a natural "tree" structure, so the metaphor is not clarifying.

If one has the perspective of an owner expanding their ownership and control (e.g. a journalist investigating PEPs), then they might consider the beneficial owner as the "root", given that they are the source of the control. Ownership-and-control relationships are the edges of the graph. They are like the sapwood through which control travels toward the entities, and that sap is being drawn from the roots (the owner).

From the perspective of asking "who controls this organization?" one might start by first drawing a node for the organization. By going through filings and declarations, a researcher can build out the ownership graph from that organization. They might then consider this organization as the root...

I don't particularly like the second analogy, however, because nothing prevents that organization from owning or controlling others. Really, it isn't a root – it is more like a branch, and the researcher chose to follow that branch towards the canopy and not towards the ground.

OO's visualization does not use the word "root" (perhaps for this reason). OO's glossary defines root as "The first or top-most directory in a hierarchy" which sounds like it's describing a filesystem.

---

root subject of a beneficial ownership network (always an entity or person)

I'm confused about subjects. In the glossary, "subject" is "The person or entity that is being referenced", which matches the colloquial meaning. On the other hand, BODS describes entity statements with "the entity that is the subject of the ownership or control"; the possible values of fields like entityType make it clear that "entity" means "organization" and not "person"; and so "the entity that is the subject" implies that the domain of the word "subject" is only entities (organizations).

So, I'm confused how a root subject can be either an entity or a person.

I might be able to suggest a clearer term if this can be clarified.

[jpmckinney]

If it means, roughly, “The person or organization that the declaration primarily describes”, then, as I suggest here, change declaration into an object, move the declaration ID into an id field on that object, and use a field like about or describes for the person or organization that the declaration primarily describes - to avoid requiring people to learn a new word “subject” - which is also used inconsistently in BODS.

[jpmckinney]

Tangentially, I think BODS should focus on the cases where BODS is likely to be adopted (primarily, BO registers).

I haven’t seen much adoption of voluntary standards by market regulators, but this is perhaps an important stakeholder for OO, so it could make sense to prioritize in BODS, if so.

I don’t know any FIU that has published data about their investigations. While some journalists do publish their data, I don’t know any that have jumped through the hoop of standards adoption (they will typically just publish their bespoke spreadsheets). So, where these two can be supported - fine - but I would not go out of my way to support them - it’ll just make the standard more complicated and hard to understand for the BO register (i.e. the main) use case.

[kd-ods]

You're right, it means roughly "The person or organization whose beneficial ownership relationships are being described”.

I'm reluctant to turn declaration into an object because it introduces a extra level of nesting. (We're suggesting that we don't have a top-level record property for the same reason.)

[jpmckinney]

Hmm, well going back to "I'm confused as to how this has been decided", I don't think you are doing users any favors by changing from a structure like:

{
  "object": {
    "id": "1".
    "field1": "a",
    "field2": "b"
  }
}

to one like:

{
  "objectId": "1",
  "objectField1": "a",
  "objectField2": "a"
}

Having a single level of nesting, as in the first example, logically groups related fields. This makes it easy for both humans and machines to both find and read, for example, all the fields related to an object. When fields are not nested, you get:

{
  "objectId": "1",
  "objectField1": "a",
  "anotherField": "x",
  "moreStuff": "y",
  "anotherThing": "z",
  "...": "...",
  "objectField2": "b"
}

In this case, it is obviously much harder for a human to discover "objectField2". And this disorder happens all the time when data is constructed by machines (where programming languages frequently implement dictionaries as unordered – assuming the code even inserts keys in a logical order).

It is also much harder for a machine to come across related fields. In the first example, the code can just lookup object and then every subfield is known to be related to that object. In the second example, the code would have to iterate over all the keys and compare to a known list of prefixes (god help it if a prefix collides with another prefix or unrelated field).

That said, I am totally in favor of removing unnecessary or useless nesting, especially when that nesting is greater than 1. But a single level of nesting generally helps users.

[tiredpixel]

Just a small sidebar without properly going into most of the points in this discussion, if I may: modelling within proper types is much easier when objects are represented as… well… objects. Having objectId, objectField1 allows me to type as objectId :: Integer, objectField1 :: String or whatever; having object.id, object.field1 allows me to type as object :: Thingy, Thingy := { id :: Integer, field1 :: String}, etc. This is convenient already with something with optional types applied, such as in Register's use of Ruby dry-types (or Python with types or proto-buf or similar), but with something with proper types (such as Haskell), this vastly simplifies pretty much everything, and allows for the writing of far cleaner (and stricter) functions. I'm personally almost always in favour of objects being modelled as objects (and the payloads take less space).

[kd-ods]

Response to issues raised above

There is a strong case for wrapping the two proposed fields up in a ‘declaration’ object.

After careful consideration, though, we’re going to keep the two fields un-wrapped and at the top level of the Statement on the basis that:

• in the conceptual model, we will be saying that “each declaration is a set of claims about the entities, people and relationships within the subject’s beneficial ownership network”, and going on to say that claims are represented by BODS Statements in the data model. Nesting a declaration object within a BODS Statement jars with the conceptual model (where the nesting/composition is the other way around).
• no more declaration properties are likely to be added to the schema. (If a strong use case develops showing additional declaration properties to be useful, then an alternative publishing schema would also need to be considered. By that I mean: publishing a collection of Statements as some kind of declaration object.)
• additional nesting is avoided (as it has been for record representation in the data model)

Accepted proposal

We will be implementing an amended version of the initial proposal. Specifically, the property names have been updated. So we will:

• Introduce an optional declaration field at the top level of each statement. The value of the field is an identifier or reference for a declaration within a publisher’s data management system. Where a statement is an element of a particular declaration (made at a point in time by a source about a declarationSubject) this field should be used to identify the declaration.
• Introduce a required declarationSubject field at the top level of all statement types. The value of the field is a recordId value for the subject of a beneficial ownership network (always an entity or person).

[jpmckinney]

Nesting a declaration object within a BODS Statement jars with the conceptual model (where the nesting/composition is the other way around).

FWIW, it's normal for objects to describe their relations, and for those relations to be fully-formed objects. In terms of what "jars", it's actually the opposite: promoting a relation's fields to top-level fields on the referring object (other than a foreign key) is unusual in data modelling (equivalent to denormalization in database design, which is typically only used for performance reasons, but that type of performance is not a concern for a data standard).

Edit: To make that sentence easier to parse: If we have objects describing a parent and a child, it's unusual to promote the field for the child's gender onto the parent's object (e.g. as first_child_gender).