Suppose we have a target — some concept in the business domain that we want to implement.
At this point, let’s assume we do not know what that concept is, and the only thing we see is its implementation — the “data structures.”
What we are trying to do here is to look at the implementation from the point of view (POV) of a computer, not from the POV of a human (e.g., a software developer).
If we look at the structures below, what information does each structure (form or shape) convey about the target ?
Highlighting semantics : removing the labels
All the labels have been deliberately removed because they are meaningful only to a human, not to a computer (we are excluding LLMs here).
Any label attached would immediately trigger the reader to interpret or comprehend the structures as representing the thing labeled, but that meaning would reside not in the structures, but in the mind of the reader.
The mind of the reader is inaccessible to computer software.
Since we want to pretend to be computers, removing all labels prevents a human reader from immediately assigning meaning to these structures.
The reader is thus forced to figure out “what these structures are about” purely based on the way they are — their “shape.”
Locating semantics : where does the meaning reside?
The target represented by these structures is the concept of a trade — a commercial transaction
(which is itself just one specific example of the more general concept of a contract — this will be elaborated on later).
Note how adding labels to the PL representation suddenly made it clear what the structure was about.
A typical representation of a trade in PLs is a set of key-value pairs (e.g. a field of a class in Java/C). Exactly the same structure could be used to represent completely unrelated targets — such as a stock of bananas in a supermarket or a picture being uploaded to a website. Hence, such a structure bears no definite relation to the target it is representing (a bit like being a symbol). The situation here is somewhat similar to using molecular descriptions as an implementation domain when the target domain is furniture: all furniture will look the same at the molecular level, and one cannot tell whether the thing being represented is a sofa or a table.
Note that adding additional PL elements like routines, procedures, or methods (as is done with classes in Java/C) does not make the structure more specific. Since we cannot use labels, adding more code only results in more uninterpretable elements.
This happens because the human interpretation of the target—the cognition of the target—does not occur by multiplying numbers, concatenating strings, or overwriting values in key–value pairs
In contrast, adding labels to the other representation (the DCM) simply adds specificity to an already existing meaning, elaborating on the information already present before introducing labels.
In contrast, adding labels to the other representation (the DCM) simply adds specificity to an existing meaning, elaborating on the information already present before the labels are introduced. The original structure (before adding labels) is not reinterpreted in a completely different way under the new light of added labels, changing its meaning unpredictably—as happened in the PL case. Instead, whatever meaning the original had is elaborated into a more specific one
