Relationships are Not Verbs
In conceptual (“ontological”) data modeling, relationships describe the structure of the connections between pairs of entity types. It is therefore inappropriate to use the part of speech that describes actions—that is to say, verbs—to describe them. Rather, since a model is intended to describe simply “what exists”, the structure should be represented by prepositions and prepositional phrases. What is the relationship of instances of one entity type to instances of another entity type? The only verb involved is “to be”—possibly in the form of “must be” or “may be”.
The year 2020 so far has produced three new books on data modeling. Each of these attempts to introduce a particular way of modeling that is oriented towards the business people whose enterprises ostensibly are being modeled.
All three are very good at defining the nouns (the things of significance) in a domain. But where relationships among those things of significance should be describing static structure, each of these authors instead use verbs to describe, in effect, what one entity type does to the other entity type. This is the domain of process modeling, not data modeling. For this reason, these books represent a very good canvas on which to make the arguments here.
- Steve Hoberman: The RoseData Stone: Achieving a Common Business Language using The Business Terms Model
- Joseph Danielewicz: Models, Metaphor, and Meaning: How Models Use Metaphors to Convey Meaning
- Ron Ross: Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business
Among other things,, the models presented here appear to be playing the role of enterprise “ontologies”. The word onto-logy was a 17th century construction (“study of things”) to describe the branch of philosophy that in fact originated with Aristotle in the third century BCE, as the study of being or the essence of things that exist.
In modern times, the term is used to describe any catalogue of terms describing the things that are assumed to exist:
- In a domain of interest
- With rules governing how these terms can be combined to make valid statements,
- Along with sanctioned inferences that can be made.
Think of “ontology” as the world’s first three-thousand-year-old hot new buzzword.
All three of the authors described here are very good about capturing the names of things that are assumed to exist—or at least categories of those things. (The boxes these gentlemen are presenting in their diagrams represent entity types—classes of things—not entities—the things themselves.) What is noteworthy is that these categories of things are labeled with nouns. The means for arriving at definitions for nouns is well established (also by Aristotle).
This is unfortunate for several reasons:
First, since our objective here is to describe what exists, the only verb that applies is “to be”. These are assertions that a relationship exists.
Second, the part of speech that is a verb describes processes and functions. The definition of a thing that exists does not include what actions it may take on another thing. The part of speech that describes the structure between two classes is the prepositional phrase. Remember Sesame Street and how Grover taught you about “over”, “under” and “around”?
Now Douglas Adams has something to say about defining relationships correctly. “the editors of The [Hitchhiker’s] Guide [to the Galaxy] got sued by the families of those who had died as a result of taking the entry on the planet Traal literally (it said ‘Ravenous Bugblatter Beasts often make a very good meal for visiting tourists’ instead of ‘Ravenous Bugblatter Beasts often make a very good meal of visiting tourists’
Picking the right word (even if it is a preposition) is important.
UML is a remarkable notation precisely because it does not describe data in terms of their structure. Rather it describes each class (analogous to an entity type) in terms of its “behavior”. This behavior then describes how it acts upon other classes. That’s fine for the object-oriented world, but if we are to define the nature of what things exist and how they are related to each other, this definition should not include a description of what one may do to another.
At about the same time (in the 1980s that James Martin and Clive Finklestein were inventing Information Engineering, Richard Barker and his colleague Harry Ellis came up with a different approach to naming relationships:
<subject entity type>
one and only one
one or more
<object entity type>.
For example, “each Project Assignment must be of one and only one Person.” (This is the first example shown in the next section below.) Here, while the structure is determined by the modeler, each of the phrases underlined here is for the business-oriented subject matter expert to evaluate as to whether it is true or not. So in this case, is it possible that you can have a Project Assignment without a Person? Can a Project Assignment be of more than one Person?
My evaluation of these three books was intended to appear in The Data Administration Newsletter, but so far only the first two have appeared. The review of Mr. Ross’ book is pending.
Unfortunately, in this newsletter, I couldn't insert the diagrams from Steve's book, so a summary of what I wanted to present here is attached to this posting.
 Steve Hoberman, 2020. The Rosedata Stone: Achieving a Common Business Language using the Business Terms Model. Technics Publications, LLC.
 Joseph Danielewicz. 2020.. Models, Metaphor, and Meaning: How Models Use Metaphors to Convey Meaning. Kindle Direct Publishing.
 Douglas Adams. 1982. The Restaurant at the End of the Universe. New York: Pocket Books, pp. 37–38.
 Aristotle. 323 BCE. Posterior Analytics, Book II. From Great Books Foundation, Ninth Year, Volume Two. Page 1.
 Armstrong Laboratory AL/HRGA. 1994. Information Integration for Concurrent Engineering. Knowledge based Systems, Inc.
 Thomas A. Bruce. 1992. Designing Quality Databases with IDEF1X Information Models. Dorset House.
 James Martin. 1987. Recommended Diagramming Standards for Analysts and Programmers.
 David Hay. 2020. "Relationships are not Verbs". The Data Administration Newsletter. [ https://tdan.com/relationships-are-not-verbs-part-one/26996 ]
"It is therefore inappropriate to use the part of speech that describes actions—that is to say, verbs—to describe them."
I am of the opposite opinion: relationships must be described with expressive verbs.
Entities are things that exist. Knowledge about the world, however, only arises in combination with the relationships between things.
Relationships are states and are expressed via state verbs.
A thing alone that exists makes no sense in everyday life. Only when I know how the thing is embedded in the environment: what it has to do with other things, how it is connected to them, can I classify the thing and include it in my actions.
"Second, the part of speech that is a verb describes processes and functions."
Verbs can describe not only processes and functions but also states. And that is exactly what we do in the conceptual data model aka Information Model.
State verbs describe situations without change and without dynamics. See Wikipedia https://en.wikipedia.org/wiki/Stative_verb
Examples of state verbs: lies on, contained in, bought from, owns, fits to
States often describe consequences of actions, processes and functions. That is why the past tense is also a way of expressing them.
"Book bought by customer" is a state, a fact that arose from the process of buying the book.
Using only to be does not lead to a usable model.
If the only permitted relationship between employee and department is
"each employee must be in one and only one department"
how do you express the facts
"each employee works for several departments"
"each employee is paid by one and only one department"
"each employee is administered by one and only one department"
"each employee leads one and only one department"
I'd like to add some remarks to statements from your main article ( https://tdan.com/relationships-are-not-verbs-part-one/26996):
"But that’s why not using verbs is important. Using a verb that was used casually in conversation is too easy. What does the relationship really mean? That’s harder."
I agree with the two last sentences. The answer to "What does the relationship really mean?" is given in a verb that exactly, unequivocally, in plain English states this meaning. And to find these verbs is hard.
"Moreover, while the structure was created by the modeler, the truth of each underlined phrase must be determined by a business-oriented subject-matter expert who knows nothing about modeling."
Information modelling is about connecting business-oriented know-how with models. So the business-expert must know about (conceptual) modelling. In the Information Model we express the truth of the underlined phrase in a way that a) the business expert can understand it and b) that IT-people see the structure of things and their relationships.
"Properly done, the sentences should seem obvious."
This implies, that the reader has to do some interpreation. Which is nothing else than applying the appropriate state verb to the relationship. Why not write down the this verb and make interpretation (by every reader) superfluous.
Stefan Berner 2019: Information modelling - A method for improving understanding and accuracy in your collaboration, vdf Zurich
Define relationship.. From my point of view it simple indicates a repeating set of data. There's no activity involved in data being stored in one place and referenced in another. However if users think of activities which generate data from a certain context, this activity may be expressed with a verb.
Therefor I argue that indeed 'Relationships are not verbs'. The activity should be part of a different modeling effort, the activity modeling. It is possible to place such verbs on lines between entities to depict the underlying data structure, but they still are part of different modeling perspectives.
Facts such as "Customer 99 is called Jack" is a mere expression which does not denote activity. The data structure can be modelled as "<Customer> is called <Nick Name>". In that the information grammer can be seen, but still the relationship itself is not the verb "is called" but "Customer Nick Name".
Now the added activity may describe "Customer 99" with the nickname "Jack". But the "naming of customers" is then the activity. The employees will most likely not call this process "is called".
So, indeed the relationships are not verbs, and yet some verbs can make it very clear of what is meant. I would not go further than to define that as adding phrases to relationships to annotate and improve readability.
Luckily the Fact Oriented Modeling method FCO-IM makes the static verbalizations possible, and the tool CaseTalk, allows to annotate the relationships with phrases for both incoming an outgoing navigation of the modeled data. The relationships themselves are simply fact types such as "Customer Nick Name".