The Nature and Experience of Semiosphere Boundaries

I have been having an interesting discussion with Sentence First blogger Stan Carey regarding semiosphere boundaries, and I posted the following comment on his site. I thought I’d repeat it here then elaborate on it.

I’m no expert on Lotman (author of many semiotics papers and coiner of the term “semiosphere”), having only begun to read his work, and I also recognize and agree that there is no such thing as a fixed and easily recognized boundary between semiospheres. Your comment about the boundary really being some sort of  “permeable membrane” is one I agree with. I don’t think from what I have read that Lotman would disagree with you on that point, as he describes the boundary in the following way:

Insofar as the space of the semiosphere has an abstract character, its boundary cannot be visualized by means of concrete imagination. Just as in mathematics the border represents a multiplicity of points, belonging simultaneously to both the internal and external space, the semiotic border is represented by the sum of bilingual translatable “filters”, passing through which the text is translated into another language … situated outside the given semiosphere. (“On the Semiosphere”, Juri Lotman)

I do like his biosphere analogy, and it brings to mind another possible analogy that might be useful, namely that of an “ecosystem”. I’ll be looking into that soon. My notion (and as always it is a laypersons notion) is that the problem of description of a particular ecosystem presents the same puzzle as the identification and description of a semiosphere.

What’s in the ecosystem and what’s outside of it? If we’re talking about a salt marsh ecosystem, for example, where does the geographic border lie? Which creatures are part of the system and which ones are strangers to it (just travelling through)?

If a predator in the woods abutting the salt marsh happens to occasionally eat a creature from the salt marsh when they stray too far from home, does that make the predator part of the salt marsh ecosystem or not? What if they primarily eat forest critters? What if they primarily eat salt marsh critters? What if they eat equal amounts of forest and salt marsh critters?

What we see in this example is that the predator is an edge creature relative to the defined forest and salt marsh ecosystems. When we make this story about a particular individual creature, then whether the predator is in one or another ecosystem is dependent on how that ecosystem has been defined generally.

To the creature, the distinction is meaningless. It lives in both places, walks ground that is sometimes wooded and solid and sometimes muddy and loose. It eats what it can catch from either place. From the predator’s individual point of view, the world consists of bits of both ecosystems. In fact, from their point of view they probably would not recognize that they lived on the margins of two very different environments.

Now add to this the two individual prespectives of a salt marsh prey creature and a forest prey creature. Their typical experience, understanding and adaptation is of the more frequently encountered predators in their milieu. In fact they may have evolved special protections or strategies for foiling these common dangers.

If our predator is mostly a forest feeder, then the forest prey may be well adapted to avoid it, while the salt marsh prey may not. The salt marsh prey in this case may not understand or recognize the danger at all. Or else, if the individual salt marsh creature had spent some time with his pals at the edge of the forest, he may ultimately recognize the predator, although it might take a few moments to react.

Look, an individual creature does not typically experience a disjointed reality. The transition from forest to salt marsh is gradual (but recognizable). Our predator may have a worldview that includes elements of both the forest and the salt marsh. By virtue of this combined perception, the predator may experience what would be considered neither salt marsh nor forest, but the combination and unification of this edge reality.

To turn this back into a discussion of semantics, then…

If we equate our edge creature to a person with knowledge of two different domains (yourself, for example), then we get the same questions: which domain is that person a member of? If he primarily communicates in American vernacular but occasionaly uses Irish idioms, is he more American? If the reverse is true, perhaps he is more Irish?

In my mind the distinction is not so important to the individual, but is certainly more important to the people who share more of the “core” and less of the “periphery” (as Lotman described it) of various spheres. But these distinctions are relative, and what is “core” to one person would be “periphery” to another.

Such an edge person can “digest” and understand many aspects of the “core” of each of the semiospheres they experience. But by virtue of their experiences at the edge between, they may not by fully aware of the all aspects of those cores. Their experience of the semiosphere (as we saw with our predator example) is also not disjointed, but forms a seamless continuum. also does not lack for complexity or meaning, even though it does not represent either core. In fact, the experience of the boundary will be exactly the same in form (but not in content) as the experience of someone else in the center of a semiosphere.

I also think that in the case of the semiosphere, as with our ecosystem example, the “boundary” or “permeable membrane” is generated only by the existence of individual creatures who bridge it and cross freely between the domains. In the case of human communication, however, I think we all are “bridging” these gaps all the time, so much so that we don’t usually experience the shift until we are reminded of them by an unfamiliar word. The mere fact of a term’s unfamiliarity proves the case of a boundary condition for the individual.

Indicators of Semiospheric Boundary

I was reading an entry at Sentence First on the surprise the author experienced when the word “razzed” was used in the body of a book on semantics, and drew a connection between the reported experience of the blog’s author upon finding the term and the notion of “semiospheres” described by Yuri Lotman.

Lotman describes the following thoughts in his paper “On the Semiosphere”, (Sign Systems Studies 33.1, 2005):

The division between the core and the periphery is a law of the internal organisation of the semiosphere. The dominant semiotic systems are located at the core.

This suggest to me that one would expect the most frequent usage of terms important to a semiosphere to occur in the dominant core.  Since a semiosphere is a continuum all the way to its edges (sharing an edge with another semiosphere), these symbols from the core should eventually and occasionally appear in the edges.

Lotman also said:

The border of semiotic space is the most important functional and structural position, giving substance to its semiotic mechanism. The border is a bilingual mechanism, translating external communications into the internal language of the semiosphere and vice versa.

When the semiosphere identifies itself with the assimilated “cultural” space, and the world which is external to itself .. then the spatial distribution of semiotic forms takes the following shape in a variety of cases: a person who, by virtue of particular talent … or type of employment … belongs to two worlds, operates as a kind of interpreter, settling in the territorial periphery …whilst the sanctuary of “culture” confines itself to the deified world situated at the centre.

The author of the post at Sentence First described himself as residing at the “elbow of Europe” and his blog has as a catch phrase “An Irishman’s blog about the Engish language. Mostly.” The book he was reading was written in the 1930’s by an American for an American lay audience, the subject being the esoteria of semiotics.

What I found ironic/interesting is how these two semiotic events (the book and the blog post) illustrate Lotman’s points so nicely.

The book on semiotics was purposefully written by one of these special people with connections to two different worlds of semiosis (one of semiotic academia, and the other of the larger American culture of his time) and is a purposeful attempt to relate the esoteric concepts of the one in the vernacular of the other. From this, to the point raised by the Sentence First author, I judge that the use of the term “razzed” to actually be a great example of the book’s attempt to reach that core audience.

The second semiotic act provides a narrative of the experience of someone sitting on the boundary between two semiospheres. While I hesitate to try to label and define this second pair of semiospheres, I think the fact that the author had to pause when he encountered the term in the context of the book shows this boundary clearly.

What I liked about the posting was that, while Lotman’s discussion is a good illustration of the semiotic landscape, and how semiotic boundaries tend to operate, Sentence First’s posting tells the story of the experience of someone actually sitting on and experiencing one of those boundaries.

Putting these two things together shows, I think, one more thing as well. As an individual person, through my life experience, I gather and collect “semiotic technique” – in other words, I learn how to communicate – in many different contexts. Being human, I tend to distill, fuse, combine, contrast, and ultimately integrate all of these semiotic capabilities into my own personal arsonal of communication. Thus armed, I am able to translate one semiotic act from one context into any of a thousand others. It is my human condition to do so.

Thus while Lotman seems to imply that a special sort of person is needed to act at the semiotic boundary, I think that it takes no special talent in particular to do so. Rather, I think it is merely dependent on having a person who is immersed in both contexts to find someone who will translate between them.

Living in My Own, Personal Semiosphere

I am sure I’m not getting this right when I read these seminal papers on the “semiosphere”, beginning with Juri Lotman’s “On The Semiosphere” (Sign Systems Studies 33.1. 2005).  I have to admit that the text has me confused a bit. On the one hand, Juri defines the semiosphere as an analog to the biosphere, a large, all pervading expanse of interconnected life on our planet. On the other hand, as he describes its features (what it is and what it is not), he describes examples of something which can be quite a bit smaller than the entirety of semantic discourse in the world. This includes the semiospheres of countries, language groups, and professional practitioners.

In other words, what I would call contexts.

Taking from this the idea that a semiosphere represents the sum total aggregate of the symbollic space around this context, I had a vision of myself, walking with a sphere of communication techniques and examples (language, art, gesture, expression) floating about me. This cloud represented not just anything that I had ever said or written (or otherwise communicated) but included the entirety of what I might ever say, or be able to say.

The sum total of everything I will ever be able to communicate.

The sum total of everything I will ever be able to communicate.

And then I thought of two of us coming together, each with our own spheres of semiotics, including personal and community symbols, and an ability to recognize and quickly adapt to contexts known to us. I imagine the interplay of our own personal semiospheres, one to the other, as we begin to try to communicate.

Having brought with ourselves the entirety of our communicative arsenol, we lob niceties and platitudes at each other, then observe which ones hook together in the shared semiotic space surrounding us. Not all of our personal spheres can be fit together – like oil and water, even if we give them both the name “liquid” cannot mix.

On first encounter, we may only recognize “the weather” and “the place” as subjects shared and in common. But as we meet over time, and we remember what connections we made before, we build the “bridge” of communication between us, and this bridge becomes our starting point for subsequent communication  (in other words, our context).

Umwelt and Semiosphere

Found this fascinating thread on Juri Lotman and his school of thought regarding the “semiosphere”, which he posited as being similar to a “biosphere”. Still reading, but wanted to capture this thread of discussion.

[Lotman] Umwelt and Semiosphere

Packaged Apps Built in Domains But Used In Contexts

Packaged applications are software systems developed by a vendor and sold to multiple customers. Those applications which include some sort of database and data storage especially are built to work in a “domain”.

The “domain” of the software application is an abstract notion of the set of contexts the software developers have designed the software to support. While the notion of “domain” as described here is similar to and related to the notion of “context”, the domain of the software only defines the potential types of symbols that can be developed. In other words, the domain defines a syntactic medium (consisting of physical signs, functions and transformations on those signs, and the encoding paradigm).

But the software application domain is NOT its context. Context, when applied to software applications, is defined by the group of people who use the software together.

There’s a difference, therefore, between how developers and designers of business software think about and design their systems, and how those systems are used in the real world. No matter how careful the development process is, no matter how rigorous and precise, no matter how closely the software matches the business requirements, and no matter how cleanly and completely the software passed its tests, the community using the software will eventually be forced to bend it to a purpose for which it was never intended.

This fact of life is the basis of several relatively new software development paradigms, including Agile and Extreme Programming, and the current Service-Oriented Architecture. In each of these cases, the recognition that the business will not pause and wait while IT formally re-writes and re-configures application systems.

One of the shared tenets of these practices is that because the business is so fluid, it is impossible to follow formal development methods. In SOA, the ultimate ideal is a situation where the software has become so configurable (and so easy to use), that it no longer requires IT expertise to change the behavior. The business users themselves are able to modify the operation of the software daily, if necessary.

Why More Than One ERP?

Why would a company – even a large company – need more than one ERP system? Why, in fact, does the world need more than one ERP system?  The answer to these questions is the same, and it all comes down to the way the human mind works.

(One reason is described on my permanent page:

 Comparison of Syntactic Media in ERP Systems)

In recent years, there has been an ongoing debate on whether IT has become a commodity or not. While this is not the subject of this article, the author tends to side with those who oppose this view. While I agree that the IT technology may be well on its way to becoming commoditized, the IT business process, being that which projects the business process onto the software of the company, will never successfully be eliminated. It may be that this core IT process eventually is performed by other groups of humans, but it will always be necessary that someone keeps the computer symbology synchronized with the business conception.

Now the most oft given argument against the notion of IT commoditization is that IT brings “competitive advantage” to the larger business by supporting local innovations. This is only partially correct, because there are lots of places where implemented systems support competitive disadvantages, and the companies don’t ever realize it. The argument for “competitive advantage” suggests that an intentional, conscious attempt has been made to create unique efficiencies in a business through IT. This may be true in some places, when a uniquely insightful organization invents a new way of seeing the world and effectively codifies it in their business processes and supporting technologies.  But more often, organizations are simply looking to steal the best ideas from someone else who has proven them to work.

ERP systems are an excellent case in point. Often organizations do not consider the effort required to configure such systems to support their unique vision of their environment. These organizations may even purchase the product with the idea that they’ll just use the software as a lever to install the best practices of the world’s leading companies, replacing their own less effective processes at the same time. These organizations are often surprised when their efforts fail, then they get quoted in the trade press saying how surprised they were at the difficulty of overcoming their worker’s resistance.

The idea that we need more than one ERP because it supports the creation of competitive advantage suggests some conscious effort at creating unique solutions to problems. This may happen sometimes, but usually the design of systems is incremental, almost random. What each group considers important evolves with time. Different organizations will be faced with different crises at different times and in different order. As events unfold, the software systems will be tweaked and tuned to address each problem. The unique order of events will drive the changes. Two organizations that begin at the same point and which face the same issues will still end up with divergent IT solutions because of two critical reasons:

  1. The order of events will never be the same between the two organizations, and
  2. The individual talents, creativity, insight and political acumen of the members of each organization will lead them to create divergent solutions.

So in fact the question should not be “Why do we need more than one ERP?” The real question should be why we would expect that only one ERP system, in the free hands of different organizations, could possibly remain the same? Over time, even if all organizations everywhere start with the same, singular ERP solution, after not a great deal of time, each one will have created their own unique system out of it. This happens whether or not the changes are competitively advantageous.

When pondering an ERP, how much time is spent considering whether the symbolic models that can be built on top of it will include the existing one? How much effort is taken BEFORE SELECTION of an ERP to determine if the symbols that are most important to the organization can be represented by that ERP? Often, it seems, surprisingly little, considering the expense, commitment and risk involved in the purchase. No, the effort comes after the purchase, when the IT department must contort and twist both the ERP itself, and the very symbol system of the organization – the very CULTURE of the organization – to complete the installation. This is one reason why ERP projects (and many others as well) fail. They were purchased not knowing whether the culture and its symbols could fit within it.

Value Proposition of Metamorphic Modeling

Integration projects are started for the following reasons: the replacement of core application systems, especially such applications as enterprise resource planning (ERP) systems,the creation of enterprise data warehousing or business intelligence capabilities, the establishment of supply chain automation and business to business “e-Commerce”, the automation of business processes through workflow,the replacement or introduction of infrastructure, especially of “middleware”, the federation and synchronization of corporate systems due to mergers, the establishment of a “service oriented architecture,” and the introduction of Semantic Web technologies, especially such things as the Resource Description Framework (RDF) and the Web Ontology Language (OWL).

Each of these endeavors have their merits and value to the organization, some more than others at different times in the organization’s lifetime. While each of these projects can share data integration requirements, they also have vast differences in requirements such as throughput, periodicity (the continuum from real-time, instant synchronization to periodic batch update), communication infrastructure, and data storage strategy. Despite the similarities in their data integration requirements, it is these other differences which have led vendors to develop products with highly diverse architectures.

One of the more interesting consequences of the diversity of integration products and architectures is that oftentimes, the vendors seem unaware of the similarities between their products, especially if they are being marketed to different types of projects. The same can often been said of their customers. It is often the case, therefore, that each new integration project is approached as completely separate and unrelated to other existing or planned integration efforts within the organization. Often this can mean that the organization assembles different teams of people to staff the different projects. Staffing such projects often focuses on the team’s familiarity with the chosen technologies or the languages used to invoke the integration tool, instead of their ability to understand and think through how the data ought to be integrated for the highest-value. This in turn leads, as well, to each project inventing its own methods for documenting (or often not documenting) the data integration.

Very large organizations may, over time, find themselves implementing examples of each of the types of projects listed above. If they don’t take a broad perspective to each problem, they are likely to find themselves with investments in several, incompatible data integration solutions, with little or no way of reusing the knowledge of data equivalences that are embedded in each one.

With this system-architectural and market environment in mind, the Metamorphic Modeling Methodology has been defined. Metamorphic Modeling provides a language for describing and capturing the integration design details of all of an organization’s data integration efforts. It presents a standard, reusable way for an organization to produce high quality designs for data integration of any type and for any purpose. Using it, the organization will find the following capabilities open to it: a “design for integration” can be codified and standardized, and a body of reusable work products can be developed with applicability across the full spectrum of data integration projects, resulting in less redundancy of effort and more consistency of results across the organization; the ability to move the data integration skills from one platform to another – the portability of method across different problem types; a cadre of practitioners can be trained in the methodology, establishing a team which can produce reliable, consistent results repeatedly, for any data integration project the organization is faced with;high-quality, consistent integration designs are more easily managed, their implementation more readily measured, tested and verified; high-value business knowledge can be retained by the organization while projects are freed to locate the best quality and most cost-effective development team they can for the chosen architecture, even and especially when the organization decides to outsource the actual development effort (perhaps even offshore); and established, pre-existing data integrations can be reverse-engineered into Metamorphic Modeling conventions, perhaps even automatically, where they can then be used as specifications for re-implementation in a different technology or tool.

The Common Features of Data Integration Tools

The tools available in the marketplace for data integration are diverse. To say that there was a standard set of required features for data integration tools would be a bit of a stretch. There is little, at the present moment, in the way of recognition that there are common features and problems in the data integration space. This is due to the fact that companies are not buying products for their ability to unify and integrate their data alone, but rather to solve some other class of problem.

On the other hand, there is a lot of commonality, both in functionality and in presentation or user interaction, among tools in very different tool categories. A certain core set of features appear again and again, and a common graphical depiction has also become nearly ubiquitous among the products.

This stereotypical user interface consists of one or more box with a list of data element names stacked vertically, and then the provided ability to connect individual columns from one box to individual columns in a second box by drawing lines between the boxes. Some of the common features of data integration tools include: a data dictionary for the schemas of the company’s applications,automated or semi-automated processes for capturing the basic schema information about these applications,and some way of linking or tying data elements from one schema to another.

Many products tout their inherent architecture as a major benefit, namely that their product presents some sort of semantic “centralized hub and spoke” model. Key features of this architecture, in addition to the typical features described above, are a language or representation for building a common, unified data (or information) model (e.g., Common Information Model) spanning the data structures of the application systems of the corporation, a technique and notation for relating the application data structures to this unified model, and the nearly universal marketing pitch touting how the centralization reduces and removes the redundancies and inefficiencies inherent in any alternate design not using their centralized hub approach.

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.

Context is Knowing Who You Are Talking To

A few years ago I ran across some very interesting research into the origins of language performed by Luc Steels at the Artifical Intelligence Laboratory of Virje Universiteit Brussel (See “Synthesising the Origins of Language and Meaning Using Co-Evolution, Self-Organisation and Level Formation“, Luc Steels, July 26, 1996. ). He basically set up some robots and had them play what he called “language games”.  Here’s part of the Abstract:

The paper reports on experiments in which robotic agents and software agents are set up to originate language and meaning. The experiments test the hypothesis that mechanisms for generating complexity commonly found in biosystems, in particular self-organisation, co-evolution, and level formation, also may explain the spontaneous formation, adaptation, and growth in complexity of language. Keywords: origins of language, origins of meaning, self-organisation, distributed agents, open systems. 1 Introduction A good way to test a model of a particular phenomenon is to build simulations or artificial systems that exhibit the same or similar phenomena as one tries to model. This methodology can also be applied to the problem of the origins of language and meaning. Concretely, experiments with robotic agents and software agents could be set up to test whether certain hypothesised mechanisms indeed lead to the formation of language and the creation of new meaning.

Interestingly enough, I ran into this work a couple years after I had written down an early musing about context (see my earlier post “The origin of a context“). At the time that I ran into Luc Steels research, I was struck with how similarly I had framed the issue. While his experiments were about much more than context, it certainly was encouraging to me that the results of the experiments he carried out corroborated my naive expressions.

Apparently, a few years later (1999-2000), the Artificial Intelligence Laboratory at Vrije University continued the experiment, including a much richer experimental and linguistic setup than the original work. The introduction to this further research (apparently funded in part by Sony) even depicts a “robot” conversation very much like the conversation I describe in my post (only with better graphics…)

The basic setup of the experiment was as follows. Two computers, two digital cameras, and microphones and speakers permitting the software to “talk”. The cameras had some sort of pointing mechanism (laser pointers, I think) and faced a white board on which various shapes of different colors were arrayed randomly. The two software agents took turns pointing their laser pointers at the shapes and then generating various sounds. As the game continued, each agent would try to mimic the sounds they heard each other make while pointing at specific objects. Over time, the two agents were able to replicate the sounds when pointing at the same objects.

In terms of what I consider to be context, these experiments showed that it was possible for two “autonomous agents” to come to agreement on the “terminology” they would mutually use to refer to the same external perceptions (images of colored objects seen through a digital camera). Once trained, the two agents could “converse” about the objects, even pointing them out to each other and correctly finding the objects referred to when mentioned.

These experiments also showed that if you take software agents who have been trained separately (with other partner agents) and put them together, they will go through a period of renegotiation of terms and pronunciations. The robot experiments show a dramatic, destructive period in which the robots almost start over, generating an entirely new language, but finally the two agents again converge on something they agree on.

I’m not sure if the study continued to research context, per se. The later study included “mobile” agents and permitted interactions with several agents in a consecutive fashion. This showed the slow “evolution” of the language (a convergence of terminology amongst several agents) among a larger group of agents. I suspect, that unless the experimenters explicitly looked for this, they may have missed this detail (I’d be interested in finding out).

What would have been terrific is if the agent kept track of WHO it was talking to as well as what was being talked about. It is that extra piece of information which makes up a context. If an agent were able to learn the terminology of one agent, then learn the language of another, it could act as a translator between the two by keeping track of who it was talking with (and switching contexts…). Under my view, context is just the recognition of who I’m talking to and thus the selection of the correct variant of language and terminology to adapt to that audience.

Human ability to switch contexts so easily is due to our ability to remember how various concepts are described amongst specific communities. I’ve always said, until the computer can have a conversation with me and then come up with its own data structures to represent the concepts we discuss, I’ll be employed… Now I’m getting a little worried…

%d bloggers like this: