re: On the “Significance of Numbers”

Clinton Mah wrote a post (SemanticHacker: Significance of Numbers) regarding probabilities and semantics where he used an example of a colleague eating a can of soup, but not realizing implications of the message on the label. This was my response:

Context is always the key. In your example, the number had units (mg) so you have a beginning of the context. Then you also have the ingredient listed (sodium) and the fact that this was on a can of soup, so presumably part of the context is “a person eating a can of soup”. In your example, it is the broader context that provides the meaning to the number.

This broader context includes the fact that the government has mandated that the can be labelled, and that the label indicate the amount of sodium. The government mandated this label in order that the manufacturer communicate to the customer this measurement. As a consumer of the soup, asside from having to read the can’s label, I have to recall that there is a context mandating the label. But the trouble here is not that I don’t know there’s a context, it is rather that I’m not completely “read-in” to that context. I don’t remember that the actual daily recommended amount of sodium is 900 mg. Even if I don’t remember the daily serving, I can presume that there must be one that I could compare to the measurement indicated on the label, due to the fact that there is the label and it has that measurement.

My experience of the context “eating a can of soup in an environment where the government has forced the manufacturer to report a sodium amount to me” may be incomplete. This just goes to show that I can exist and interact with a context, even if I’m not a principal player in defining it.

Presumably, the meaning of the probability associated with a term should tell me (and any software using the number) of a relative confidence in a particular “interpretation” of the term. But this interpretation of the number (not the term) is general. It does not tell me the actual meaning of the term in the “term’s context”, it merely associates the term to several other terms telling me the one’s it is most likely associated to given other instances of the term experienced earlier.

This meaning of the probability applies to every such probability number in the software system.

Did I miss your point? The meaning of words is context dependent. By capturing your “semantic signature” you really are capturing an approximation of that context, but you have not captured the meaning of the term, and the probability numbers have not either.

Yes, the more terms I put into my search, the more likely it is that I will find other documents from the same context. But as you say, the training set must have included enough samples from that context to make a statistically useful estimate (else I won’t find my context correctly).

I don’t know, I think there must be something a bit different between the actual, experiential semantics in my head and that statistical estimation of semantics that you are describing here. At least in magnitude if not in kind.


The Context Continuum

So my previous post about the “Origins of a Context” was grossly simplistic. That is however, a good way to get a basic idea out there. Obviously there are many complex factors and layers of influence that affect the extent and content of a context.

One way to look at context is as a continuum from the very small to the very large. This “size” measurement is a reflection of the number of people who share the context, not necessarily the size of the population of concepts and symbols within it.

As I’ve said in other places, a context is defined by its membership first, and its content second.

Hence, by my definition, the smallest context is defined by a single human being. That person would create contexts of a private nature: mementos of their life and personal mnemonics. If the person were artistic, they might create art and artifacts of personal importance. These personal symbols would remain private until the person shares them with someone else.

As soon as they have been shared, even if only with one other person, these artifacts take on additional meaning and become community symbols. Once they have been placed into a larger community, further refinement and re-enforcement of the symbol becomes a community activity. For the original “artist”, their conception can take on a life of its own, and they may lose control over it.

As more and more people become aware of a symbol, the broader the context becomes. But in addition, the symbol itself will begin to change its meaning, either becoming much more generic and broad, or tightening up to some exclusively minimized idea. As soon as this happens (and it happens almost immediately after it begins to be shared) correct interpretation of the symbol must, by definition, take into account which context’s version of the symbol is being considered. Other writers have referred to this issue as one of identifying the “situational” meaning of the symbol, while others talk about the symbol’s “frame”. In my mind these are the same thing as what I’m calling “context”.

So what does this continuum of contexts look like? I’ve drawn a first draft diagram of the smooth transition from personal symbol to the “semiosphere”. It identifies the types and relative sizes of contexts and presents some of the names of their various features. It also shows where in the continuum various types of study and research fall.

I make no claims of absolute accuracy here, and invite comments from experts in these fields (and any others who want to project onto my template).


Continuum of Context from Single Person to Semiosphere

Continuum of Context from Single Person to Semiosphere


The Origin of a Context

On this blog and in the writings of many other people through history, the idea of “context” as a component of the definition, interpretation and usage of symbols plays a large role. Be it called “situational” or “cultural” or any of a number of sometimes more and sometimes less academic notions, context provides the key (just as a cipher is a key to an encryption code) to interpreting any message. Without knowing the context, many messages will be uninterpretable, or even worse, unrecognizable.

But what is “context” really? Where does it come from? Here is my decidedly informal discription.


Two people thinking their own thoughts meet for the first time

A conversation starts and one tells a story.

The other listens, interpreting silently what she hears into her own experiences.

She then responds, reflecting what she thought she heard, but with a variation or two. 

Conversation Begins

Conversation Begins

The first person agrees with some of her response. He hadn’t at first thought of the variation, but now that she’s mentioned it, he knows she’s on to something.


Conversation Ends Context Begins

Conversation Ends Context Begins

The two part company, carrying a memory of their conversation.

When they meet again, they will reinforce and reiterate their common perceptions on the matter. This is the origin point of CONTEXT: the set of principles and concepts that the two agree about, and the shared vocabulary they have used to describe them.

Software Applications As Perception

“The agent has a scheme of individuation whereby it carves the world up into manageable pieces.”                    K. Devlin, “Situation Theory and Situation Semantics”, whitepaper, 2004, Stanford University.

A software application creates and stores repeated examples of symbols defined within the context of a particular human endeavor, representing a perceived conceptual reality, and encoded into signs using electro-magnetic syntactic media. While the software may be linked through automated sensors to an external environment, it is dependent on human perception and translation to capture and create these symbols. Business applications are almost entirely dependent on human perception to recognize events and observations. That said, while the original “perceptions” are made by human agents, the software, by virtue of the automation of the capture of these perceptions, can be said to “perceive” such events (although this should be considered a metaphor).

Application design is in large part the crystallization of a particular set of perceptions of the world for purposes of providing a regular, repeatable mechanism to record a set of like events and occurrences (data). In essence, the things important to be perceived (concepts) either for their regularity or their utility by some human endeavor (context) will determine the data structures (signs) that will be established, and therefore the data (symbols) that can be recorded by the software system.

The aspects important to the recognition and/or use of these repeated events (e.g., the inferences and conclusions to be derived from their occurence) determines the features or qualities and relationships that the application will record.

Good application design anticipates the questions that might be usefully asked about a situation, but it also limits the information to be collected to certain essentials. This is done purposefully because of the fundamental requirement that the attributes collected must be perceived and then encoded into the symbology within the limited power of automated perceptual systems (relative to human perceptual channels).

In other words, because a human is often the PERCEIVER for an application, the application is dependent on the mental and physical activity of the person to capture (encode) the events. In this role, while the human may perceive a wealth of information, the limits of practicality imposed by the human-computer interface (HCI) guarantees that the application will record only a tiny subset of the possible information.

This does not pose any particular problem, per se (except in creating a brittleness in the software in the face of future contextual change), but just illustrates further how the context of the application is more significantly constrained than either the perceived reality or even the boundaries formed from the limits of human discourse of the event. This inequality can be represented by this naive formulation:

Μ(Ac) << Μ(Hc)

The meaning contained in the Application A defined by the context c is much less than the meaning (information) contained in the Human H perception of the context.

It is important also to note that:

Μ(Ac) is a subset of Μ(Hc)

The meaning contained in the Application A is a subset of the meaning contained in the Human H.

No aspect of the application will contain more information than what the human can perceive. This is not to imply that the humans will necessarily be consciously aware of the information within the application. There are whole classes of applications which are intended to collect information otherwise imperceptible to the human directly. In this manner, applications may act as augmentations of human perceptual abilities. But these applications do not of themselves create new conceptions of reality posteriori to their development, but rather are designed explicitly to search for and recognize (perceive) specific events beyond the perception of natural human senses. Even in these situations, the software can only recognize and record symbols representing the subset of possible measurements/features that their human designers have defined for them.

Hence, while software applications may be said to perceive the world, they are limited to the perceptions chosen a priori by their human designers.

Good Summary on How Engineers Define Symbols

An interesting summary of how software engineers are constrained to develop data structures based on their locality is presented in a comment by “katelinkins” at this blog discussing a book about how “information is used“. I think, however, it ends on a note that suggests a bit of wishful thinking, in suggesting that engineers don’t really

…KNOW and UNDERSTAND the code…

and implying that additional effort  by them will permit

validating the representations upfront to aid in development of common taxonomy and shared context

I wasn’t sure whether the comment was suggesting that only software engineers “continually fall short” in this effort, or if she was suggesting a greater human failing.

While software developers can be an arrogant lot (I saw a description of “information arrogance” earlier in this discussion stream, and we can definitely fall into those traps, as anyone else can too), it is not always arrogance that causes our designs not to fit exactly everyone’s expectations.

Software developers do define symbols based on their regional context. But it gets even more constrained than that, because they must define the “symbology” based on what they know at a particular point in time and from a very small circle of sources, even if the software is intended for broad usage.

The fundamental problem is that there is ALWAYS another point of view. The thing that I find endlessly fascinating, actually, is that even though a piece of software was written for one particular business context (no matter how broad or constrained that is), someday, somewhere, a different group of users will figure out how to use the system in an entirely different context.

So, for example, the software application written for the US market that gets sold overseas and is used productively anyway, if not completely or in the same fashion, is a tremendous success, in my mind. This is how such applications as SAP (the product of German software development) has had such great success (if not such great love) worldwide!

I don’t believe there is such thing as a “universal ontology” for any subject matter. In this I think I’m in agreement with some of the other posts on this discussion thread, since the same problem arises in organizing library indexes for various types of the “information seeker” in any search. While having different sets of symbols and conceptions  among a diverse set of communicating humans can muddy the  space of our discourse, we at least have a capacity to compartmentalize these divergent views and switch between them at will. We can even become expert at switching contexts and mediating between people from different contexts.

One of the big problems with software is that it has to take what can be a set of fuzzy ideas, formalize them into a cohesive pattern of structure and logic that satisfies a certain level of rigor, and then “fix in cement” these ideas in the form of bug-free code. The end result is software that had to choose between variations and nuance which the original conceptions may not have ever tried to resolve. Software generally won’t work at all, at least in the most interesting parts of an ontology, if there is a divergence of conception within the body of intended users.

So in order to build anything at all, the developer is forced to close the discussion at some point and try their best to get as much right as is useful, even while they recognize there are variations left unhandled. Even in a mature system, where many of these semantic kinks have been worked out through ongoing negotiations with a particular user community, the software can never be flexible enough to accomodate all manner of semantic variation which presents itself over time without being revised or rewritten.

In the software development space, this fundamental tension between getting some part of the ontology working and getting all points of view universally right in a timely fashion has been one of the driving forces behind all sorts of paradigm shifts in best practices and architectures.  Until the computer software can have its own conversation with a human and negotiate its own design, I don’t see how this fundamental condition will change.

Charting The Semantic Stream

…what Man touches, he stains with meaning…
…it flows like water, permeating everything…

Each computer system presents a different view of the world. Like water sitting in bottles, bowls and buckets with different shapes, meaning fills every available nook and cranny. But just as there are not enough bottles to hold all of the water of the world, no system can hold all of the meaning man can project.

This site is dedicated to capturing my ideas regarding the movement of concepts through human-defined artifacts. The goal is to capture an impression of the nature and properties of meaning and symbol, and to discover and map how meaning flows – what changes and what remains constant – as it passes from one end of civilization to the other.

%d bloggers like this: