Nodes as encapsulated rich data

The simplest additional dimension in information structures

If two-dimensional art is intended to be representational, additional details needs to be added. Shade and light can make an object look like an out-of-focus, distant, vaguely floral form; details (line, texture, color) pull it from vague to distinct. Where art focuses on additional details that are layered on the outside, information architecture sometimes tuck those details out of sight.

Did you ever play with a Paku Paku as a kid? It has many English names; the one I grew up calling it was “fortune teller”. It’s an origami object where people put one set of information on the outside and have another person provide a couple answers to dig into their “fortune”.

Think about this object as a node. On the surface, the object says “this means something”. Open it up, and there’s more information. Not only more information, but that information leads to another layer which could literally be anything that makes sense in context of the first two layers and the interaction of people.

A Paku Paka labeled “this means something” on the outermost folds, “which can lead to a different something choice” on the next level of folds, and finally opened to a blank canvas with an upside-down “which choice” facing the viewer.

Translate that to a super simple diagram, and it could be either of the nodes as shown:

Two nodes with an attaching connection, both of which says “this means something”

But wait! There’s more! It would be really tempting to simply expand both of those nodes into a structure, call it ‘nothing new’, and walk away.

Put it as a node in a more complicated structure, where a pattern is evolving that will help others navigate and find information. A node can still be part of that navigation, and have another meaningful dimension. It can be anywhere within the structure.

Hierarchical structure with colors forming a pattern and two nodes called out as encapsulated rich data.

Digging into the details

Simple node

A node can be as simple as a data point. Detached from meaning, decontextualized, a number can still be a simple node. I’m making an extra point by using 3.14 here, because it’s actually rare that a data point have absolutely no context. That number could be your current bank account balance, or the cost of a coffee, or the span of time before your tea is steeped. We don’t know based on the provided information. But that particular number likely brought up meaningful context in your mind.

A node representing the data point “3.14”

Metadata

A very common practice in information technology is to have supporting metadata associated with a node. From SEO to search parameters and beyond, metadata enriches a data point. The number 3.14, for example, automatically registers with underlying meaningfulness for a broad swath of people. It probably starts along the lines of: circle, circumference, equation, geometry. We probably mentally label the node “π”, and consider the number as the go-to good-enough level of detail we mostly work with. In this instance, “3.14” has an expanded richness in both the label and the metadata.

A node with undetailed supporting metadata

Hierarchy

Rich encapsulated data can also be part of a hierarchy — as already alluded to. Our instinct as people steeped in hierarchical data structures everywhere is to think about that as the parent, but the reality is that encapsulated data can be anywhere in a hierarchical structure. Think about it in terms of education, of which our current systems very much leans into hierarchy and repetition as a way to disseminate understanding. Today’s lesson plans in math might center around π, making the lesson plan look something like the structure on the left. But this semester’s math course would look more like the structure on the right.

Encapsulated data in undetailed hierarchies. In the left, the encapsulation is the topmost parent. In the right, it’s a 2nd-level child.

Process

Another reason I used 3.14 as my example is because there are a goodly amount of people already thinking of equations that use π. Equations are a mathematical process, and as such fit within a process information structure.

Rich encapsulated data in the middle of a process.

Network

More than anywhere else, rich encapsulated data is part of network structures. Network structures are already incredibly complex to share, understand, draw, or define data to have software draw it into a chart. Despite that intrinsic complexity, every node in a network structure is a likely to be an encapsulation.

Think of building something, whether it’s a skyscraper or a children’s toy. In all the things that need to be considered, π becomes something important in its particular use, a subfunction of other endeavors, and could be referred to multiple times.

Rich encapsulated data as part of an undetailed network

Now think about how you are thinking about 3.14 in the past few minutes. First, there’s a good chance that, in moving from the the previous hierarchy of education and into the concept of π being part of an equation, you combined them into one complex structure in your mind. But let’s expand that idea further. Linearly through time in the course of this reading, π has been an:

• encapsulation with supporting metadata, and
• an encapsulation in an hierarchical/educational structure, and
• an encapsulation in a mathematical equation/process, and
• an encapsulation in a network of considerations.

Right now, it’s all four at once, with a different structure depending on how you are mentally referencing it and prioritizing the information. Each of those reference points is a potential information dimension.

This is one of the reasons information architecture can boggle minds. This is why it is so important to take information architecture in chunks, focus on aspects while littering structures with reminders (like circles and spectrum nodes and networks) that there’s more involved.

This is one pieces of Why learn the fundamentals of information architecture structures?