Complete Predicates, Complete Knowledge

Complete Predicates, Complete Knowledge

My last article presented a case for use of relationship predicate phrase or complete predicates, over the common use of single verb predicates, in knowledge and data modeling.

The predicate of an entity relationship, tells what a subject entity does in relationship to an object entity.

Common practice in the industry, if used at all, is to provide a single verb, rather than a complete predicate or verb phrase. Deep business understanding and mental exertion are not required of modelers who employ single verb predicates. And the outcome is incomplete information, and very often ambiguity, obfuscation and error in knowledge.

In my last article I stated, “Relationship verb phrases express the action form of the entity’s function….”

The entity definition is really a distillation of the action narrative of the entity’s relationships. What a thing is in the business architecture is based on what it does, and the doing is expressed by entity relationships.

Here I’ll demonstrate, how complete predicates create the most accurate understanding of an organization’s business architecture. The entity’s relationships are the true expressions of the entity’s business function. Therefore, each relationship’s predicate should completely narrate of action that it represents.

Action’s Form and Function

Frank Lloyd Wright observed that Form and Function are a union, as opposed to the notion that Form follows Function. In physical design, Form doesn’t just follow Function. Function follows Form. Design form, whether natural or human, both enables and simultaneously, limits function. In the design of a physical thing, its physical form and its function (use) are bound to one another.

But Wright’s understanding of function also encompassed a form’s ability to elicit a spiritual or emotional response. His building designs delivered aesthetic function, for the sense of beauty and awe they created in their union with their surroundings. A Wright building, set within its landscape, is inseparable from its function.

In business data and knowledge modeling, the union of Form and Function is absolute. The graphic form of the entity and its relationships represent a pattern of action.

With a few exceptions like Location or Address, all business entities are named functions (complex actions). Each of an entity’s relationships, represent individual actions that implement the entity’s function.

We see this principle demonstrated in Figure 1 below, with the example of Claim Exposure. Its function’s definition is:

“Claim Exposure establishes a potential for Policy loss, arising from a Claim’s obligation to compensate a Claimant for loss. This obligation is formed from the harm caused to an asset or person in a Loss Incident, in combination with in-force Policy Coverage, for the type of harm caused.”

We see these same elements of Claim’s definition express in the entities relationship verb phrases in its supporting action to Policy Claim, and its dependence on Loss Unit (Asset and Person), Policy Coverage and Claimant.

Article content
Figure 1 - Claim Exposure Illustration

Each of an Entity’s relationships represent an individual business action, while the Entity represents the sum of all those relationship actions. The taxonomy (differentiation) of Claim Exposure isn’t based on its name and definition. It is differentiated according to the sum of the actions represented by its relationships.  The name and definition of the entity’s function flow from these.

Imagine the quality of Business Glossary terms possible from this kind of semantic approach, which requires actual analysis of action function that a business term names.

Simple one word verb phrases do not produce this impact, because they do not cause the modeler to form a complete understanding of the business action. Consider the typical model of Sales Order and Sales Order Item. Typically, the relationship narrative would read, “Sales Order associates Sales Order Item”, or “Sales Order has Sales Order Item”. Both are devoid of business knowledge.

The relationship of Claim Exposure to Claim, is one of functional support for Claim’s adjudication actions. But Sales Order Item’s relationship to Sales Order is formed by direct action of a Customer (a business actor). A meaningful relationship narrative is one that explains the action that forms the relationship. Attempting to meet this requirement, single predicate modelers might state that “Sales Order selects Sales Order Item”. But this is an obvious error since a business process such as Sales Order. merely controls actions, rather than performs it.  

An accurate statements of relationship would be: “A Sales Order Item is selected by a Customer for a Sales Order”, or more concisely,  “A Sales Order Item is selected for a Sales Order”, or “A Sales Order has, selected by a Customer, a Sales Order Item” if the inverse is desired.

As this example illustrates, verb phrasing with the perspective of the child entity as the sentence subject and the parent entity as the object, is often grammatically less complicated. That’s because the story of the relationship is either one of functional support by the child, or direct action used to form the child’s functional relationship with the parent.

Complete Predicates, Complete Business Architecture Knowledge

Note the relationships in Figure 1 above, between Policy and Claim, as well as Policy Coverage and Claim Exposure. These relationships are member to a much broader set of business process interactions that form an organization’s comprehensive business process narrative. Policies have their own Policy Administration business processes. Claim function is a set of actions that begins with the first request for compensation and encompasses the entire claim adjudication process right up to final Settlement and Payment actions. A Claim is completely dependent on the Policy as expressed in the relationships predicate statement of standing and control.

No business process stands by itself. All functions of the business are integrated in an organization’s business architecture. The totality of all these relationship (action) narratives, form a total picture of the organization’s business architecture.

Language is a visualization tool. Modeling maximizes that visualization by graphically structuring the business architecture’s action narrative. Complete predicates provide the complete information needed for an accurate and comprehensive understanding of an enterprise’s business architecture.

Conclusion

If one seeks quality business knowledge and coherent data models, the definition of entity function is predicated on the knowledge of individual relationship actions. The need to produce useful complete predicates, forces the modeler to understand the nature of action performed, which eliminates ambiguity and obfuscation of business function.

Complete predicates deliver maximum information for validation of the model, and maximizes information imparted by the model.

My next article will explain how entity attributes, which are the characteristics of entity function, are expressions of the individual actions of the entity relationships themselves.

To view or add a comment, sign in

More articles by Donavon Gooldy

  • Archetypes of Business Knowledge – When Employee is not a Person

    Introduction Do you believe classifying an Employee as a Person in a Business Ontology, as illustrated in Figure 1, is…

  • What is Data?

    A leader of one of the consulting firms I’ve worked for in my career, answered our title question by stating that…

    1 Comment
  • Focusing The Language of Modeling

    A respondent to one of my recent LinkedIn posts commented that the terminology I use is confusing. Indeed, the way I…

  • Normalization Of Knowledge

    Normalization is NOT an engineering exercise. The central principle that underlies its rules is that data redundancy…

    3 Comments
  • Simple or Complex Predicates in Business Knowledge

    I was recently admonished, because my relationship verb phrases do not conform to a standard of “elementary…

  • Data Ontology & Taxonomy Primer – Part 6

    One of this series’ central principles of business knowledge and data modeling is that the things we model are not mere…

    5 Comments
  • Data Ontology & Taxonomy Primer – Part 5

    In Part Five, the Archetype basis of Ontology we introduced in Part Four, will be examined with greater nuance. As…

  • Data Ontology & Taxonomy Primer – Part 4

    It’s been a while since the last article in this series, and there is a lot more subject matter to cover as we explore…

    6 Comments
  • Data Ontology & Taxonomy Primer – Part 3

    We discovered in our last article’s examination of Data Ontology & Taxonomy, that business data describes human…

    2 Comments
  • Data Ontology & Taxonomy Primer – Part 2

    The first article in this series, presented Ontology & Taxonomy as a unified framework or methodology, rather than two…

Others also viewed

Explore content categories