The relevance of semantics

I mean: the meaningfulness of meaning

This post has three parts:

1. The two sides of semantics: separating them with a line.
2. Engineering a symbol system: folding through the line to make both sides match.
3. Conclusions: final remarks making the two previous sections not only interesting but hopefully useful.

The two sides of semantics

Semantics are either extremely important or extremely irrelevant, depending on the meaning of the sentence: “we are discussing semantics”.

There are two ways in which semantics may be discussed, according to the two ways in the semiotics triangle:

Semiotics triangle: Concept, object, symbol. Ref: John F. Sowa

Side note: I took the image from Ontology, Metadata, and Semiotics, by John F. Sowa. It is a great read, certainly better than this Medium post; consider reading it if you have not already.

If semantics are being discussed, it is normally in the connection between concepts and symbols, and there are two ways in which the discussion may happen:

1. Less relevant: there is an agreement at the concept level, but the words or names for it the topic of discussion. This discussion may still be relevant in some contexts, as the names may be misleading. For example it has been argued that “technical debt” may be misleading as something to leverage. Finding terms that cause less confusion and misunderstanding is always good, but not as relevant as the other way around.
2. More relevant: there is an agreement at the symbol level but there is no agreement at the concept level. For example two founders may discuss about ways to get “exposure”, having different concepts for it, being personally famous for one and having a well-known product for the other. Each one has its own merits depending on the purpose or goal (pragmatics).

We can say that point 1 lowers the argument, while point 2 raises it, at least according to Figure 2 in The Pragmatic Web: Putting Rules in Context, by H. Weigand, A. Paschke.

Semantic-pragmatic knowledge transformation

We could write volumes adding nuance to that figure, but the only thing that we need for now are the two ways in which semantics may be discussed:

1. Tired: in relation with their symbols, or
2. Wired: in relation with their implications.

Hypothesis: We might match both.

Engineering a symbol system

Let us represent everything with a symbol, defining symbols as set of key-value pairs, and then define aliases on those.

Keys

A key is just a symbol. To prevent the infinite regression, we need a set of primary symbols, which do not need to be fixed, i.e. different systems may use different primary symbols. Ancient alchemists could choose to use water, air, earth and fire, while current physicists may prefer fundamental dimensions. The set of primary symbols may be as arbitrarily large as necessary, but should be only as large as strictly necessary. A primary symbol has a single key-value pair, with the system we are defining as the key and the name of the symbol as the value, both are strings, e.g. {physics: gravity}.

Values

Values may be anything: booleans, symbols, numbers, lists, sets of key-value pairs, or any combination of the previous. Think of JSON. By restricting the possible values we may have different families of symbol systems, e.g. if only booleans are possible we obtain a binary symbol system.

Aliases

We can split the aliases in two parts separated by a slash, as prefix/suffix. With the prefix being a reference to the system at use, and the suffix the alias (as a term) in that system.

For example, biology/cetacean could be an alias for {biology/mammal, biology/habitat: geography/body_of_water} and biology/mammal is at the same time the alias for {biology/mammary_glands: yes, anatomy/neocortex: yes, anatomy/middle_ear_bones: 3}. If an alias takes the role of both key and value, its expansion results in all its key-value pairs being added to the containing set without nesting.

We can easily see that without aliases, the entire system would not be manageable. With aliases, we have a structured dictionary, built bottom-up. An alias cannot be used before being defined, preventing cyclic definitions. Alias expansion is arbitrarily long (and nested), but finite and deterministic.

Conclusions

I have not done a systematic approach of the state of the art, but the traditional approaches start with the top class (e.g. owl:Thing) and then define subclasses explicitly, which may use triples to represent the properties of each class.

In this case taxonomies are implicit, emerging instead of being defined by specifying relations between symbols (the less relevant side of semantics), we define the symbols by their key-value pairs, i.e. relations with other symbols (the more relevant side of semantics). The resulting taxonomies are not trees but more similar to [infinite sets of] lattices, representing the containment of symbols, which are sets. Infinity is introduced in several points, e.g. the nesting of symbols as keys, and the infinite numbers that may be used as the values of any key.

The possibilities for the structure of a symbol may be constrained, e.g. defining a “schema” of the valid structure. For example, by allowing only for primary symbols in the keys, we would have a system equivalent to RDF. If in addition the values are considered only as “truthy” and “falsy”, i.e. e.g. {something: 3} and {something: 4} would be considered “equivalent”, as both are “truthy” for something. In that case we would have a finite lattice defining all possible symbols.

Without constraining the possibilities for symbol structure, this compositional approach to define symbols and the relations between them is admittedly hard to apply but still hopefully interesting and useful. For example, the compositional approach is to traditional ways to define ontologies analogous to what structural typing is to object oriented programing (OOP). In fact, polymorphism and the set of messages that an object may accept is the “big idea” of OOP.

Therefore, this compositional approach may be most useful as a guiding or design principle for current practices in knowledge engineering:

1. In case of a discussion or disagreement, it is worth asking if the discussion is about the meaning of a symbol, the relationship with other symbols, or the alias to assign to it. The last option might be the least relevant, especially considering the prefixes system.
2. Given an alias without a prefix, like “tomato”, we may choose to solve the question of what we mean with a prefix, like legal/tomato or biology/tomato where the former has considerations like the use, e.g. being part of the main course, like a legal/vegetable, and the latter has considerations like the part of the plant it corresponds to, having biology/seeds like any other biology/fruit. After considering the prefixes, we may merge several (or all) symbol systems, specifying that a legal/tomato is the same thing as a biology/tomato. This kind of alignment would be theoretically equivalent to ontology alignment but practically much easier due to the next point. Note: aliases without prefixes would allow for polysemy, and prefixes would avoid it. Polysemic words like “Ruby” are not necessarily a problem for search engines nowadays.
3. We might have a good principle to design an ontology if we consider that classes should be introduced in an ontology if and only if they correspond to a different representation in this symbol system, ultimately translated to primary symbols. If such representation is then made explicit with axioms and restrictions on properties, alignment might be much easier than it is for average ontologies nowadays, especially if the primary symbols can be mapped manually and with certainty.

In summary, this is an exercise to try to refocus discussions about semantics on knowledge about things, and less on the names of those things.

I learned very early the difference between knowing the name of something and knowing something. — Richard P. Feynman

How to cite this

This post is far from an academic paper, but it can be peer reviewed and cited. To review it, simply comment on this post. To cite it, use this:

@misc{semantics_relevance_trylks,
  author = {trylks},
  title = {The relevance of semantics},
  year = {2021},
  publisher = {Medium},
  journal = {Medium post},
  howpublished = {\url{}},
}

Acknowledgements

Thank you for reading. Hope this helps — trylks

References

1. Sowa, John F. “Ontology, metadata, and semiotics.” International conference on conceptual structures. Springer, Berlin, Heidelberg, 2000.
2. Weigand, H. and A. Paschke. “The Pragmatic Web: Putting Rules in Context.” RuleML (2012).