My Little Obsession with Symbols

Diagrams are amazing—whether it’s a signal flow diagram, UML, or an electronics schematic. There’s something special about creating a concise, elegant, and high-information-density representation of a system. If you agree, then this is the article for you!

Many types of diagrams have been honed over decades, with standards for electrical, electronic, hydraulic, and code diagrams refined to the point that we often don’t even think about where a symbol came from—its meaning has simply become universal. These standards often construct symbols from smaller, well-defined graphical elements in ways that resemble Mayan hieroglyphs or Chinese characters, a connection that is often overlooked in how we teach them. Within these simple arrangements of symbols lies vast untapped potential for better communication.

The visual language of schematics—and how they encode the systems they represent—contains a beauty and elegance all its own. Exploring this landscape has become one of my life’s little follies, with the occasional useful product—such as a font for an elemental spell language (see Figure 1).

So, for this article, my thesis is that formal diagrams serve a dual purpose: they function as both a true written human language, with their own well-defined syntax and grammar for precise communication between people, and as a static programming language, providing a decidable declarative specification of how systems should work. These diagrams can be described as semasiographic—conveying meaning without speech—but I’d like to coin the term schemographic for this more specialized dual-purpose subset, where there is a formal description on both sides. This encompasses many formal systems, from electronics diagrams to process control diagrams to standard mathematical notation.

We’re going to focus mostly on the symbols themselves, so let’s start by looking at how symbols can be decomposed into glyphs—or assembled from them.

Linguistic Analogies

Written human language is considered easier to learn when it builds on familiar glyphs, symbols, or constructions, follows regular grammar, and maintains logical, consistent composition rules. It follows that the same should hold for schematic symbols: if we want them to be easy, usable, and memorable, they should derive from known symbols and follow structured composition principles. In fact, the pressure toward regularity is unavoidable—without a systematic compositional framework, symbols become more arbitrary, harder to recall, and less adaptable, making learning and use more difficult rather than easier.

This is true of the symbols we're focused on in this article, which are mostly covered by the IEC, ISO, and ANSI standards organizations. Unsurprisingly, these symbols share deep similarities with written languages, particularly those that are logographic or semasiographic. Symbols representing similar functions within a standard use or repeat similar glyphs. Figure 2 shows the symbols for thermal break switches and fluid flow switches from the ANSI and IEC standards. In both cases, there's a root symbol (or radical) for a switch and a modifier (which acts broadly like a diacritic) affixed to indicate thermal or flow. Mayan hieroglyphs and Chinese characters are apt analogies here. Both combine smaller graphical elements into structured symbols with specific meanings; there's a radical glyph that anchors meaning, and modifying glyphs that change or augment that meaning. For example, consider the charater 澡 meaning to bathe, which consists of the radical 氵 (water), combined with 喿, which is itself composed of three 口 (mouth) glyphs over a 木 (tree) glyph. I'm going to use the words 'radical' and 'diacritic' more broadly than usual. However their meaning will not change, and it will help maintain the analogy, so I think this is fine. Glyphs can also be transformed, but we'll come back to that later.

Just as with written languages, these standards define precise rules for constructing symbols while leaving room for slight visual variation.

However, schematic symbols differ from conversational languages in important ways. They prioritize precise, high-density, domain-specific information over general-purpose communication. While symbols act very much like words, how symbols relate to each other—that is, the grammar—is quite different. We'll leave the grammar mostly alone for this article and stay focused on the syntactic rules for the symbols themselves.

When looking at a set of symbols, it is often easy to see commonalities and how to decompose them into glyphs, and the standards mostly spell out what the available glyphs are. However, constructing new symbols from them—or understanding the rules governing such construction—is much less straightforward. Like human writing, not all diacritics can be applied to all radicals; some diacritics can change meaning, and some complete symbols can be repurposed as diacritics.

We'll need to establish rules for this and develop a more formal or mathematical framework for systematically manipulating symbols. We're going to split the problem into a mathematical way of combining glyphs graphically, and then a way to attach and propagate meaning and enforce syntax.

An Algebra of Symbol Construction

We can start by defining the graphical domain of our symbols as the unit square, and symbols as being just some set of points in that domain. How we get those point sets doesn't really matter. They could be directly defined as a subset or as the result of some curve function, or anything else that results in a point set. This idea mirrors the point-wise parametric curve embedding used when drawing graphs or how TrueType fonts store glyphs as parametric Bézier splines. Defining things this way means that, however the point sets are created, combining them becomes the simple set-theory union operation. Additionally, the scaling and translation transforms also have obvious implementations, for example as matrices applied to each point in a set.

To make our lives easier, we'll say there is only one kind of transform ($T$) that scales a symbol and translates it into place. Despite T having a matrix representation, we'll denote it as a linear function to avoid any confusion about associativity or commutativity. We'll also add an identity (empty) symbol and an identity transform.

Every new symbol then can be expressed as the union of a radical with zero or more diacritics in a nice expression:

$$ S = R_0 \cup T(S_1) \cup T(S_2) \cup \ldots $$

where $S$ is any symbol or glyph, and $R_0$ is a radical glyph. In these terms, the $T(S)$ terms are diacritics. This is where I'm pushing the meaning of 'diacritic' to its limit, but I still think it is the right way to view it, as they do change the meaning of the radical even though they may contain more of the final symbol than the radical does. Figure 3 uses the symbols for pipe valves as an example, with three diacritics for the globe valve, plug valve, and lastly a ball valve.

While this is an eminently simple algebra to implement, very few combinations of glyphs will result in a valid meaningful symbol. For that, we're going to need some syntactic rules and start typing our glyphs.

Attributes and Connections

Symbols and glyphs have some obvious intrinsic attributes, such as indicating that a component is electronic (e.g., a diode) or mechanical. Note that this does not mean values associated with a component (like a 100-ohm resistor), but attributes that are common to all things represented by the symbol. These intrinsic properties mirror the meanings a human would take from the symbol, and while they might be useful in modeling later, they're not that helpful syntactically. That is, they are not helpful in specifying how glyphs are composed.

For that, we'll start by plagiarizing the ideas of links, link types, and connectors from link grammars (ST91). Connectors could also be called ports, anchors, or handles. We'll use "ports," as the idea of peripheral ports on a computer sits nicely here.

In a link grammar, each word can only connect in specific ways; that is, the links are typed, and the connectors or ports on the words at either end of a link must match appropriately. Figure 4 shows how a sentence can be parsed with links. We're considering symbols, not words, so the link types are different, but the idea is the same: a mechanical-out type port has to connect to a mechanical-in type port; it cannot connect to an optical port.

So, we'll give every glyph some number of ports, with each port having a type, and a link can be formed to another port if the types match appropriately. If we think of that type as a constraint, then linking two ports satisfies that constraint on both ends. Composing glyphs then either amalgamates the ports that cannot be satisfied or links the ports that can.

For instance, an electrical resistor has two electrical ports; adding a "tap" diacritic to a resistor transforms it into a variable resistor, adding a third electrical port as well as a mechanical port. Similarly, a switch radical begins with two electrical ports and one mechanical port. Applying a push-button diacritic satisfies the mechanical port while leaving the two electrical ports. The symbols in Figure 1 and 2 also follow this pattern, with either the flow or thermal diacritic satisfying the mechanical port.

While this idea matches how we connect symbols in diagrams and gives a good starting point, link grammars are not quite the right formalism. They don't really encapsulate hierarchies; in fact, they impose flatness, which is unhelpful here. Fortunately, we can convert this glyph link satisfaction problem into a more general unification problem. Our glyph syntax system then falls under the large, old, well-studied, and rich field of Unification Grammars (Sag85), for which there are tons of formal analysis and tools available.

To do this, we represent each port's constraints as a logical equation involving its type rather than by its type alone, and resolving the set of all such equations for the final symbol forms our unification problem. Once again, our final symbol has the form of a set of things. Alas, a simple union operation doesn't quite work here, as it would not resolve any of the unioned equations. Instead, we need something like the unification operator, which also happens to be denoted $\cup$.

The scale and translate transform doesn't change any of the typing, so if we set $T$ to be an identity function on the set of equations, we can again write our composition problem as the unification of a radical with zero or more diacritics:

$$ S = R_0 \cup T(S_1) \cup T(S_2) \cup \ldots $$

where this time $S$ represents the set of link equations.

So now we can redefine a symbol as a tuple consisting of a set of points on the unit square along with a set of link-type equations. The new transform function is the respective old transform function with the identity function. And the overall composition operator is the respective union and unification operators.

Isn’t that neat?

Wrapping Up

While we've focusing on the symbols here, this connecting and resolving of ports is exactly what we use connected edges for when drawing symbols and diagrams, and it's how words connect to form phrases. It also has a solid mathematical foundation from which we can validate any syntax we can encode as link types.

We can also enumerate possible symbols by finding glyph sets that satisfy some link type.

Obviously there are lots of devils in the details, but even a simple implementation is expressive enough to cover most of the syntax used by the above standards.

Again, this linking also scales to the whole diagram, at which point we can use formal verification algorithms to validate that the entire diagram follows these rules.

At this point, we have enough to start implementing a symbols library based on these ideas. The work-in-progress is here (GitHub link to follow).

Conclusions

This algebra of schematic symbol construction, along with the concept of typed links for connections, provides a structured way to both design and validate formal symbols and diagrams. This approach allows us to think of schematic symbols not only as tools for representing components but as a genuine language—a way to communicate precise information both to other humans and to automated tools.

By focusing on the theory from a human writing perspective, with just enough pushback from the formal mathematical theory to make the theory consistent, we gain a method of building a visual language that should be rapid to learn and straightforward to use while retaining a lot of formal machinery for verification and processing.

It isn't immediately obvious to me that these ideas are sufficiently better than how symbol libraries have been built before, but as the systems we interact with every day grow ever more complex, I do know we need methods for better, more nuanced, and more precise ways to communicate about them. In the meantime, I'm enjoying the folly of exploration.

This project has become part of a much larger project to do with capturing diagrams for Analogous System Modeling, which usually uses the somewhat obtuse Bond Graph formalism for their diagrams. However, an electronics or hydraulic schematic captures a lot of the same information and is much easier to work with, mostly because much more effort has been put into that kind of CAD program. My hope is that I can leverage the ideas laid out here into a capture package that is intuitive to learn and use and works in any of these domains.

References and further reading