Service Oriented Computing and Tech Shamans

The Design and the Designer – Part 8

There is a lot of talk about Service Oriented Computing these days – mostly by people who don’t seem to understand what it really stands for.

Until now, we have very good models of infrastructure engineering and applications engineering, but we are yet to see a reasonable model for process engineering and structural engineering in the computing science. This could be because of the unfolding of services as a primary business model has just begun and we have not yet understood what service really is.

A very successful billionaire once told me that the Services Automation is several orders of magnitude more significant than the industrial revolution. The explanation he offered for this significance was very striking. It has the beauty of simplicity and the brilliance of Truth to it. According to him, the basis of industrial revolution is control of resources and centralization of knowledge and power. Who ever can control and marshal resources and centralize and guard knowledge becomes wealthy.

But, the services revolution is exactly opposite. Its basis is decentralization of information, power and knowledge. Its basic premise is that we should use resources as when required without really possessing them. Look at the business models of today, especially the Internet. Its basic principle is making information equally available to everyone, and make use of resources as when required without possessing any resource at all.

But, how is this possible? Why would the wealthy people - who became wealthy because of the exact opposite principle - allow such a thing to happen? Why would they want to let go of their control and let go of their wealth?

Well, the answer is that it was not made possible by the wealthy and rich business people. Most of the computing science and the consequent business models are the creations of enlightened hippies. They were the only people capable of such subtlety of thought and action. They even managed to get vast amounts of funding from the very same people that they resolved to dethrone them from their seats of power!!

Let's look at the evolution of computing science, its absorption by the 'industry' and the unseen hand of the hippy.

On one hand, there is IBM and all its 'industrial' representatives and on the other hand there were tech-shamans.

What did IBM and its representatives contribute to the computing science? They tried big, fat main frame machines, resource hogging, hierarchical operating systems like MVS, they tried unusable programming languages like COBOL and they tried to push for data modeling rooted in their three hundred years of arrogance. Now they are trying Java and J2EE. In the software engineering side, they perpetrated process centric methodologies. All these technologies, methodologies, disciplines have one thing in common - they all aim to make the process expensive, aimed to clear the "owner's" inventory and make their clients/customer pay a very heavy price. And, more importantly - they have some kind of 'lock-in' of the customer built into all of them. In the long run - all of them are very expensive - the price paid by people who adopted COBOL during the Y2K issue must be an eye opener. And, who spent the money to resolve the Y2K bug, and who earned it? The people who bought COBOL paid the price, and the people who invented COBOL made the money. The same thing is currently happening with Java and J2EE - all in the name of open computing. The Java technology is an invention of the large computer hardware companies - their aim is to push their hardware, and consequently - the Java Technology demands more and more of 'centralized' computing power. As a language, it is doesn't maintain a clean separation between the virtual machine, the environment and the programming constructs. It looks like SmallTalk, but its philosophy is that of ADA - a big, fat language with too many features and no simplicity. And, today these are the same people who are talking about service oriented architectures and design methodologies. How will it ever work? When they talk about service - they have only one thing in their mind, the customer serving them!! One critical look at the current SOA will reveal that it is a tiger disguised as a holy cow - the SOA wants more and more resources, introduces more and more technologies, centralizes all information and knowledge in the system and very cleanly hands over the customer to the corporations. It is nothing but the mainframe machines, COBOL and process centric methodologies put together in a new disguise.

On the other hand, what was the invention of the tech-shamans of computing science? They invented workstations, powerful user interfaces, networking, distributed computing, cryptography, artificial intelligence, gaming, multi-media, Internet, Unix Operating system, C-like programming languages, hypertext, grid computing and relational data bases, agile programming, extreme programming, design centric processes and problem solving and so on. The list goes on and on. More importantly, they invented open sources programming, making freely available their ideas and designs. Is there any real programmer on earth who learnt his programming from IBM and what it stands for? Is it even possible to learn programming in such closed circuit, big brother environments? All programmers learn programming from the open sources - by contributing to open sources, by using open sources, by reading and following the open sources programming models. One thing common in all their contributions - is a clean separation of concerns, extraordinary simplicity of design, an approach to very clearly communicate the problem-solving techniques, and all these above inventions do not make it heavy on the users - they take responsibility for their own mistakes, they are all designed to tolerate errors from the environment, all of them are extraordinarily reliable and consequently very cheap to own. Neither the inventors nor their inventions charge the customer for their own mistakes. The SOA is known to this community decades ago. In fact, all the systems and technologies built by were all inherently "service-oriented". They are very economical in their resource usage, and they all freely disseminate knowledge and information. I call these people the tech-shamans and hippies of computing science.

I need to explain what I mean by Shaman and Hippy.

In general, the public image of a hippy is a person who is a drug addict and a general misfit in the society, who cannot live in the usual demands of the societal pressures. But, in reality - the hippies are people who are "free" - they are free from the usual tendency to acquire material possessions, they are free from the usual conventions of linear thought processes, and they are free from fear, greed and the usual trappings. They only desire for ecstasy - a few degenerated hippies may get this ecstasy from drugs - but the majority of them get it from problem-solving, from the joy of work. They do not demand any other form of payment. For them, money, power, fame etc., are all byproducts. Their main interest is in the 'kick' they get in understanding, the suffering they go through in the effort required to assimilate and internalize information and in problem-solving - the application of knowledge. A recent psychological survey revealed that problem-solving – working on difficult problems – releases the same chemicals that are involved in drugs – it produces a ‘kick’ very similar to drugs and sex.

Shamans are evolved ‘hippies’ – in a way hippies of the highest order. He could sit with a plant for a month, talk to it to find out whether its herbs could be eaten. Finally he may eat the herb and die – that would be his contribution to humanity. On the other hand, there are priests – the organized institutional worker - working for control and centralization as opposed to the Shaman who acts as a bridge between two worlds.

In no other field of human Endeavour, the fight between the free spirited hippy and the controlling industrialist are more marked and visible than in the computing science. The history of computing science is littered with records of such fiercely fought battles - the failure and success of Multix and UNIX, the great debate on relational and hierarchical data models, between what is ugly and beautiful and so on. The hippies had Dijkstra, Knuth, Ken Thompson, Tony Hoare, Writh, and E.F. Codd as their keepers of faith and the industrialists had large bank accounts. The history of human beings recorded rather well that it is fearlessness and truth that win the war, not power, money and ignorance. The result is well known even before the war started.

But, this time the hippies learned their lessons from history. They were no longer interested in fighting useless battles. By definition, their knowledge and inventions are available to every one - including the control minded industrialist. The evolution of computing science really nothing but a statement of how the industry assimilated the contribution of the hippies and shamans, and is slowly and painfully learning to respect them and their contributions.

Some examples and illustrations are probably required at this stage.

First, let's take Object Oriented Programming. For any normal human being, objectivity is the hardest thing to understand. Many philosophers, over the last few millenniums devoted their entire lives to understand and explain to us objectivity. The aim of science is an objective understanding and explanation of the reality - did it succeed?

Some tech shamans like Marvin Minsky and others - unleashed in the early sixties - some thing called Frames as a knowledge representation scheme, and some other shamans developed SmallTalk programming language. Even the names give their Shamanistic origins. So, object oriented programming was born. This was a very original idea - for those who understand it, it appeared very simple, and for those who did not understand it - it was an alluring mystery, whose secrets must be cracked at any cost. This division continues even till today - very few programmers really understand object oriented programming - the rest of them use UML. The object oriented analysis, modeling and the modeling languages are nothing but the industry's attempt to assimilate a very hippy concept. After all the literature, tools, systems, training courses that the industry developed for Object Oriented Programming - no one can still explain 'how to' identify and design an 'Object'. This is still the best kept secret of programming - passed on from the Master to his most accomplished disciple.

Again in the Sixties, the patron saints of tech-shamans - Dijkstra and Tony Hoare - unleashed some thing called concurrent or non-linear programming. The concept simply is that it is more efficient use of resources if programming is relieved of its tiresome linearity. How many people can think non-linearly? The shaman hardware designers went ahead and fundamentally altered the way the machine is constructed - they made the machines interrupt driven, in other words, the behavior of the machine is non-deterministic and thus non-linear. Countless coding soldiers wasted probably billions of lines of code trying to understand how to configure such a non-deterministic machine. If you look carefully at the core of the unreliable software - you can trace it to the so called 'dynamic' aspects of the environment - aspects that are not known apriori. How can you design a program for an environment that you cannot predict it at the time of writing the program? For the shamans - it is a simple problem with an obvious solution, and for a control minded industrial freak - it is unthinkable.

One thing is very obvious. More than seventy percent of the programming projects undertaken by the industry are failures - they run into too many technical and budget problems, they run into performance and reliability problems. But, name one open sources project that has any of these problems?

The industry tried to tackle this problem using their age old technique and very old, useless thinking tools. They created software engineering methodologies and they write tons of documentation of their technical designs and programs, they spend millions of dollars in testing. But, for some mysterious reason - open sources systems do not have any such things. They don't come with tons of specification documents, high level designs, pseudo code etc.

Anywhere you care to look - this division is obvious. There are two streams of computing science and two streams of people. Let me call them programmers and coders, or if you don't mind - shamans and priests. Even computing literature can be divided into two classes - the shaman literature and the priest literature. This division is very marked especially in Software Engineering.

Software Engineering is perhaps the only discipline that aims to teach problem-solving. Its interest is not in providing some specific solutions to specific problems, but to teach problem-solving. But, the big, fat books on Software Engineering written by priests do not get the central idea. They only confuse it even further – they describe methodologies and processes, basically they preach what people should be doing, without even giving a hint of how to do something.

The best software engineering books were written by Shamans – people like Dijkstra, Knuth, Weinberg, Rob Pike, and Bertrand Mayer and so on. Knuth’s 70 page paper on Errors of Tex is perhaps the best description of the software engineering process ever published. These are works that are full of insights and techniques – not some religious preaching.

But, what is the secret of the shaman?

The secret is - as all best kept secrets in the history are - is very simple and very obvious. The tech-shamans are basically builders and engineers. The metaphorical links between Free Masons and Free Software Foundation is hard to miss. They understand the process of design, they understand engineering as a discipline, and they understand that the process of making something and its final object of creation are two completely different things altogether.

Abstraction, Pattern Recognition and Problem Solving

The Design and the Designer – Part 6

A gap of more than two weeks interrupts the flow. But, the gap is probably required because from here – the approach is very different. Until now, I largely covered a lot of breadth, and was able to give examples in one paragraph – an approach that may not be sufficient from now onwards. It is like getting into the second chapter of a book – by nature, it gets a little deeper and a bit more boring.

The difference between Architecture and Engineering is like the difference between Music and Sound. Architecture is a word that is associated with many disciplines today – we talk of architects of nations, architects of enterprises and corporations, architects of cities, plantation forests, gardens, buildings, computers and information systems. Sometimes, this word is also used in relation to effects produced by an individual or a group of people – architects of success or failure, architects of war and of destiny. After the last Great War, this discipline seemed to have become main stream.

Even though, these days we use the term in its verb form, actually it exists only as a noun. The architect produces architecture – what he does is not architecture, but design. Therefore, the process used is the process of design, but the end product is “Architecture”. All architects are designers of a particular kind.

What does really an architect do?

Let’s consider the traditional architecture of buildings as an example. Even though the structural engineers deride architects as people who basically add unnecessary embellishments that do not have serve any functional purpose, in reality the job of an architect is one of transformation much like the work of an alchemist.

What the alchemist is to science, the architect is to engineering.

His work involves understanding the essence or meaning of space and transforming this understanding into an engineering problem.

Sounds abstruse even to me. We need some detailed explanation.

An architect basically brings meaning to space. An engineer does not make any distinction between kitchen and living room – both are basically enclosed spaces as far as the engineer is concerned. But, for people living in a house, kitchen and living room have very distinct functions, how they relate to these spaces is very different, the time they spend in these spaces is very different. It is the job of the architect to understand the function of a kitchen or a living room, and their relation to the people who use them and then somehow be able to express it in terms of certain ‘spatial’ characteristics – their geometry, placement, the equipment provided in that space. Basically, the architect defines what a kitchen is in certain engineering terms.

In short, the mysterious craft of architecture is very simple to express in words. The architect performs a series of semantic transformations; the last transformation achieves the feat of converting the problem into a structural engineering problem. If the alchemist transforms lead into gold, the architect transforms gold into lead – in a manner of speaking.

The reason why structural engineers do not respect architects is perhaps because of the fact that over the years, the community of architects was successful in creating a set of transformations that are universally accepted and understood, and the engineers themselves understand the difference between the kitchen and living room without the help of an architect. So, they do not see the necessity of an architect for the most common problems like the construction of a house, or a bridge any more.

In short, architects create new abstractions. An abstraction is an information structure – that codifies meaning objectively, an information structure that is universally understood. The power of abstraction is such that – if we have to state in one single line the difference between human being and an animal – we can say that the difference is the ability to come up with an abstraction.

What is an abstraction? A “tree” is an abstraction. ‘A Tree’ does not exist anywhere in the physical world – there are mango trees, there are lemon trees, there are all kinds of other trees, but there is no such entity called ‘tree’ – it is a pure abstraction that exists only in our consciousness. It helps us to group all mango trees, all lemon trees and all other trees in one sweep, and capture the ‘essential treeness’ that all of them share. Similarly, ‘A Man’ does not exist any where except in our consciousness – there is a John, there is a Joe, there is an Adam – but where is ‘Man’?

It took several thousands of years for us to come up with some very simple abstractions that we take it for granted today. One such example is the number system and the simple arithmetic of additions and subtractions. In ancient times, when people did not know the basic math, the methods they used for trading were very funny. If one goat equals two bags of rice (purely a concept of quantity decided by its value, there was really no such thing as ‘one’ goat and ‘two’ bags of rice) and if you want to want to exchange two goats, then what do you if you do not understand what is one and what is two? You give one goat, take two bags of rice, and then give one more goat again and take another two bags of rice. A very cumbersome process indeed – isn’t it?

But, what can people do if they do not know what is one and what is two? The numbers are very powerful abstractions.

An abstraction is valid only if it is completely objective. This condition means that an abstraction must mean exactly the same thing to everyone. The difference between an abstraction and a concept is in how strictly this condition is applied. A concept is not very strict in imposing the condition of objectivity. For example, “world” is a concept – but what I mean by world and what you mean by world can be somewhat different.

Abstractions, concepts or semantic types – are all information structures. It is a unit of information that retains the meaning of something, and is made accessible to everyone.

What is interesting is how we as humans acquire concepts and abstractions. We do it so naturally – we do not even realize that we are dealing with abstractions and concepts all the time. But, it is an amazingly complex process.

When as children we learn our alphabet – all we are shown is one particular shape of the alphabet. Your teachers writes ‘a’ in your notebook, and you practice recognizing ‘a’ and writing it yourself. That’s about it – after that you can recognize ‘a’ in what ever shape, size and form it appears – and you can recognize ‘a’ instantaneously. What you as a child accomplished is an amazing feat – by understanding one particular ‘a’ – you somehow extracted the ‘a-ness’ and then can apply that understanding of ‘a-ness’ like a flash. You can recognize ‘a’ in which ever font it is written, in millions of different handwriting samples. You do not need to be taught to recognize ‘a’ by going through several thousand samples, and various complex rules of recognition.

Such a simple act of extracting the meaning by understanding from one single illustration and then apply it on the fly to recognize millions of variations is an amazingly human ability – something very difficult for machines to do. Computers cannot even recognize their own hand writing!!

It is easy for a computer to produce millions of different ways of writing – you can type a word into a document, and then change the font any number of times. Computers are quite good at such manipulations. But, they are miserable when it comes to ‘recognition’ – at least until now. Suppose you take a printout of a document – and then use a scanner to scan the same document, connected to the same computer, and then try and reproduce the document in its original form ( a process called optical character recognition) – almost always you get a document with too many ‘errors’. The OCR programs are very complex where as the document creating programs (like Microsoft Word) are relatively simple. The OCR programs use several thousand ‘sample’ character sets, and ‘train’ the computer to recognize the ‘a-ness’. But, till now there is no foolproof method to accomplish this.

What makes us so good at pattern creation, extraction and recognition? Let’s leave that question to psychologists. However, this particular ability is at the heart of problem solving. In a most generalized sense, architecture, design, engineering, diagnosis are all a form of problem solving. Problem-Solving and Design involves an innate ability to recognize and categorize patterns, abstractions and concepts. Patterns, abstractions and concepts require associative thinking.

In the earlier posts, I mentioned about two kinds of thinking, two different processes of problem solving and so on. I tried to make a distinction between demonstrative reasoning, and heuristic reasoning. It is well recognized that the art of problem solving involves heuristic methods – for example, using analogy, generalization, reduction, specialization and so on. We also described in some detail about various forms of non-linear thinking – be it creativity, right brain thinking, lateral thinking, out of box thinking and so on.

Associative thinking and heuristic/plausible reasoning are the most generalized forms of non-linear thinking and problem-solving.

How does associative thinking work really and how can we use it systematically?

Here is a small exercise:

Let’s pick up some word randomly – let’s say it is Sun. Write down ten other words that come to your mind (without thinking) when you think of Sun – for example, star, heat, light, earth, round, fire, red, day, night, energy, Egypt, Japan and so on. Now, how is Sun connected with Egypt? The relationship between these two very different concepts is one association and it is association of some meaning. For example, Egyptians used to worship Sun God. Therefore, the relationship between these two concepts is “worshippers of”.

In the last post, I discussed about four structural relationships – hierarchy, network, hypertext and set. The relationship between Sun and Egypt is none of the four structural relationships. It can – at best – be represented in terms of a hypertext relationship, but it is in fact a “semantic relationship” – it is the inherent meaning that connects these two concepts.

Nasruddin – while solving a logic puzzle uses his associative network to come up with a completely out of the box solution. We need such an associative mental network to work with analogies, to work with induction, to generalize something, and from generalization to specialization and so on.

Another advantage with the associative thinking is that – you can recall your entire memory starting at any point. I suggest doing this as a fun exercise. Start with Sun – and write down all the words that come to your mind, and then for every word connected with Sun, write down all the words you can think of. For example, expand Egypt – something like – desert, pyramids, Africa, Nile, Pharaohs, Moses and so on.

Unfortunately, we are never taught how to make and keep an associative memory consciously. We are taught how to practice organizing our knowledge using the structural relationships, and we are taught how to use demonstrative (logical) reasoning, even though our brain uses an associative structure to organize its own memory and experiences. We are naturally gifted with the ability to organize and relate to our experience using associative networks. But, we are never taught how to practice it formally. As a consequence, our memory is a very randomly formed associative, semantic network that we cannot use efficiently.

The real trick of problem solving is nothing but consciously organizing our knowledge and experiences as an inner semantic network of concepts and relationships. In other words, if we can make and keep associative networks of our knowledge and experiences, then we have a better chance of becoming better problem solvers.

More on this in the next post.

Non-Linear Thinking and Structures

The Design and the Designer – Part 5

In the last post, I made a brief mention of Nasruddin, Heuristics and Non-Linear Thinking. I shall continue in this post on the same theme and establish the role of semantics in Design and Non-Linear Thinking, and explore some techniques of practicing non-linear thinking.

First, here is a very brief synthesis of the previous posts on this subject: In the previous posts, I applied law of 2 and tried to demonstrate the underlying unity of the theme in various disciplines – which is referred to as Plausible and Demonstrative, Creative and Logical, Synthesis and Analysis, Right Brain and Left Brain, Linear and Non-Linear, Heuristic and Rational and so forth. Largely, the conclusion that one can reach is that there are two distinctive types of thinking – which are interdependent on each other, but at the same time have very different functions and applications. We termed the functions of these two types as – recognition of problems and finding solutions to problems. We also presented a few laws of synthesis – from various fields – particularly societies, management, computing science and consciousness.

Before we get into Semantics, let’s examine linear thinking and non-linear thinking in some detail – with some examples and techniques of how to switch from one to another.

Logic – at least the way Socrates and his disciples developed it – is largely linear. This is carried over into mathematics as well. Logic mostly depends on reasoning from evidence. The early Artificial Intelligence (which is neither artificial nor intelligence) applications ran into some problems with the linear reasoning and there are now several attempts to develop non-linear reasoning systems. Such logics in AI are called “non-classical” reasoning systems. Here is a classic example of linear and non-linear reasoning – it involves a very well known logic puzzle.

Three monks and three cannibals were traveling together because of some strange circumstances – even though naturally there cannot be any friendship and trust among such a diametrically opposite groups. If at any time, the cannibals outnumber the monks – they will eat them. Now, they came to a river bank and they had to cross the river. There was only one boat. The boat can only carry two people at a time. Now, your problem is to devise a strategy to transport the monks and the cannibals safely across the river.

The usual linear reasoning system will start with River Bank-1: 3M, 3C, River Bank2: 0M, 0C as the initial state of the system, and will try to devise a series of moves that will establish the desired final state - River Bank1:- 0M, 0C, River Bank2: 3M, 3C. It is a simple puzzle – you start with something like first two cannibals will travel, one will come back, two monks will then go etc., and you can easily arrive at the final state.

Suppose you give the problem to Nasruddin, what do you think he will do? He will listen to your descriptions, and even before you have completed your narration, he will jump from his chair and shout with the excitement of a child “I know, I know - the monks will take the bridge, and the cannibals will take the boat”.

It is a perfectly valid solution to the problem – isn’t it? Then you tell him “look Nasruddin, I did not say that there was a bridge”. Nasruddin will reply, “Well – you did not say that there was no bridge either”. Now, you modify the problem description, and you will add another constraint to the problem – there are no bridges. “Well, in that case, the monks take the helicopter” will be Nasruddin’s answer. By this time, you get very frustrated and shout back at him – “I want you to solve the problem – not avoid it”. But, for Nasruddin, there was no problem there to be solved. Can you see how he eliminates the problem instead of trying to solve it?

No matter, how hard you try, you cannot contain Nasruddin. He will always think of exploiting some constraint that is not included in the problem definition and use that as a means to eliminate the problem.

The AI community in the last thirty years tried and discovered several techniques for “programming Nasruddin type behavior” into the computer programmers – with some reasonable success. I have no intention of boring you with the Non-Monotonic Reasoning systems here. But what is the technique of Nasruddin?

One, Nasruddin does not depend on “evidence” as the only way of establishing the existence of something. All formal logical systems depend on evidence as the only means of establishing “truth”. For example, if I tell you that all visitors from Canopus are fools, and you know that Mr. X is a visitor from Canopus, you can confidently establish the truth that this particular Mr. X is a fool. But, there is a catch. Suppose, if this particular Mr. X is not a visitor from Canopus, then what are you going to do? You cannot establish anything. He may or may not be a fool. You can conclude Mr. X’s foolishness, only if you know that he is a visitor from Canopus.

We need facts to recognize truth, but Nasruddin does not rely on such petty things like facts to recognize truth. According to Nasruddin, some thing does not have to be a fact for it to be true. Kurt Gödel proved this mathematically – it is known as Gödel’s incompleteness theorem. The incompleteness theorem states that in any formal system, there always exists a statement which is “known” to be true, but cannot be proved.

Rabindranath Tagore – with the brevity that a poet alone can command – says it beautifully.

“If I say that the earth is flat – you inform me that my near sight is false.
If say that the stars are the fireflies attracted to the moon, the candle of the sky – you inform me that my far sight is false. My dear logician – in your presence, I prefer to be blind”.

*****

The second principle that Nasruddin mastered is the System’s Principle – understand the problem by studying its relationship to the larger environment in which it is only but a part. I wrote about this principle in part 2 of this series of articles.

In the specific case of monks and cannibals – all Nasruddin does is to bring his knowledge of the larger environment to solve the problem. The minute you tell him about the river and the boat, he can think of a bridge. He can bring his knowledge of traveling in the air, or swim in the water. Or, he will say that the monks – using their magical techniques – will vanish and reappear on the other side. Or, he will say that the monks will use their secret herbs and put the cannibals to sleep. His possibilities to come up a solution are infinite.

The study of system level relationships requires knowledge of semantics – or the “meaning” of things. There are basically two types of relationships – structural and semantic. It is important to distinguish between these two types of relationships. Though, in logic and other sciences, we are mostly taught how to study the structural relationships, in fact, our mind works naturally very well with semantic relationships.

A few examples from various fields may be in order here.

In language, grammar defines the structural relationships. In English, a valid sentence must have a subject, a verb, an orbject/predicate. And, there are various rules that define the relationships between various parts of speech. These relationships are basically structural – they govern the structure of the sentence. We can say that water is triangular – it is a grammatically valid sentence, but completely meaningless.

In information systems there are basically four types of structural relationships. By information systems I do not mean just software applications. Any system that organizes knowledge and depends on that organization is an information system. By this definition, societies, cultures, various disciplines of study are all information systems.

The first – and simplest structural relationship is hierarchy. This relationship in information systems is called “IS-A” relationship. A “IS-A” B. This could be interpreted in several different ways:

• B is the parent of A
• B is the boss of A
• B is part of A
• B is subsumed by A
• B is the root of A

Entire systems, organizations, societies are modeled based on this one particular relationship. Most hierarchical structures use this relationship as the primary relationship. The different sections in this blog-page have a parent-child relationship with the master page. There are basically five sub-sections – header, footer, posts, author information, archives – each of them is a “child” of the main blog page. Similarly, many corporations have a hierarchical structure – with the owner of the corporation at the top. The “semantics” of this relationship connotes ownership and protection.

The second structural relationship is network relationship. In such a structure, elements, or objects at the same level can be connected. This is called “sibling” relationship. A “IS-A brother of” B. The relationship basically means that two things are at the same level. It connotes competition and/or collobaration.

There are two other types of structural relationships in information systems hyper-text and groups. Both these relationships are somewhat non-linear relationships, but nonetheless, they are structural relationships.

The Set, and Hyper-Text are more complex structural relationships than a simple hierarchy and a Network. A set uses a function to create a structure. For example, you can say that all integers belong to a set. You can then define a function that determines an integer and therefore, the membership to the set. The members in the set may not have any particular relationship – they have something in common – that’s all. This is how most social groups are formed. The function gives an identity to the set and therefore to all its members. All people “born” in US are “Americans”. “Being born” in the US determines the identity of the set called Americans.

A Hyper-Text relationship is much more interesting relationships. It does not relate two nodes, but instead it relates content from one node to another node. All web pages use this structure extensively. For example, I can provide a link to an article in wikipedia in one of my articles in this blog. This does not mean that this blog as a whole and wikipedia share any relationship; it also does not mean that this article and the wikipedia share any relationship, and it also does not mean that this article as a whole has any relationship to that article in wikipedia. This relationship connotes friendship. There is no function, there is no responsibility, and there is no ownership in this relationship.

Using these four relationships, we can explain almost all “order” in our world. We defined the basic family relationships (parent-child, sibling), groups and friendships.

So, where is the place for Semantic Relationships?

We conveniently left out the most important, most complex, wonderful, problematic and the most beautiful relationship of all– that of the lover and the beloved. None of the above relationships explain that relationship – do they? What is the relationship of a husband and wife? What is the relationship of a teacher and a student? Friendship comes closest, but these relationships transcend friendship.

This is the realm of semantics – which is the topic of next post.