Modeling the communication about the data as expressed by domain experts can clash with technical oriented viewpoints. For instance the world of reference data and catalogs which might use codes, versus the actual values that bear meaning to the business. This article explores how an example case of preferred pronouns can unite people with different viewpoints.

As a starter: The perspective of the business we may state a few facts about persons:

Person 1 is called Jo.

Person 1 has lastname Smith.

Person 1 prefers the pronoun They/Them.

All this is in a days work for us as information modeler. The facts can be modeled as the image shows:

Once the discussions are started on pronouns we might realize these should really be managed in a separate list, a reference table, or a catalog of some sort. So, let's make some statements for a typical catalog in which we combine the catalog type, the entry codes, and the descriptive labels.

Pronouns 900 is labeled as They/Them.

Pronouns 901 is labeled as She/Her.

Pronouns 902 is labeled as He/Him.

A diagram from these fact expressions can be depicted as such:

The labels are annotated to specify they contain localized values. CaseTalk will generate artifacts to store additional translations for the label values.

To prepare the integration with the pronouns catalog itself, we need to state a fact which connects the object type Person with the Catalog Entry codes:

Person 1 prefers the pronoun code 900.

By adding the above fact, which will allow the code to be stored with the person object type. We can now mark the original Preferred Pronoun fact type derivable.

To truly bring these constructs together, we will need to describe how the Preferred Pronoun is derived using the pronoun code and the catalog entries. We can do that by providing a text and display that in the diagram.

By showing all information in one diagram we can illustrate the connection between the business oriented facts and the catalog oriented facts. Now we mark the business oriented fact types derivable. We now have an information model which can communicate facts for both the business side as the IT side, without loosing any communication. The generated ERD from this model looks like two distinct tables, connected by a database constraint.

That's how a catalog model, or reference tables may be modeled. Naturally, this is just an example, there are many other ways to structure such facts. The important thing to take home from this article is that it does not require difficult technical constructs which lack communication, to model and serve both viewpoints. Fact oriented modeling allows anything that can be stated in facts to be modeled without loosing any meaning, or communication.

The model can be downloaded from github.