We see Einstein's brain as a network of Prolog programs. Many facts we hold in our brains are not really scalar facts, but units of rules and facts (Prolog programs) that results in a solid fact when it is submitted a set of facts. For example, if Niels Bohr (left of Einstein) asks Einstein, if he wishes to have lunch now, there isn't a "couple of bytes" in his brain storing a Yes or No answer. Rather, there may be one or more Prolog programs in Einstein's head that goes through this process:

1. It recognizes that it is being addressed. This recognition occurs through the sequence of words Niels speaks and Einstein hears.
   
2. These Prolog programs consider the truth of various facts. Some of these facts may be simple and some are complex, cascading decisions in themselves. A simple fact would be a signal from the part of the brain telling Einstein he requires nourishment. A complex fact would be a question in itself such as, "Is this a good time to break?" Of course, that question triggers other questions.
3. Once all of the facts comprising this Prolog program are found to be true, a fact is generated that states: I wish to have lunch now.
4. This fact triggers an action that mobilizes and coorindates Einstein's vocal chords, lungs and muscles in and around his mouth to produce a sound that Niels hears as "Yes".

The Prolog programs within Einstein and Niels Bohr's heads communicate to each other using electrical charges. Prolog programs in their respective heads communicate to the Prolog programs in the other person's head through the vocalization of data, body language, or written communication. At another level, groups of humans, such as Congress relate to other groups of people or invididuals via the interchange of Prolog programs too.

Regular Web Services

The difference between a web of SCL Web Services and a Web of regular Web Services is that the former exchanges richer packets of information than the latter. These richer packets of information are SCL fragments that consist of facts and rules intended to supplement the facts and rules stored at the called SCL Web Service. Regular Web Services, by which I mean, "as is normally used", pass a set of parameters that plug into a function. Since these functions perform very specific, well-understood tasks, they require very specific input parameters.

An example of a regular Web Service (let's call it GetRetailTax) would be a service that calculates the retail sales tax rate for a given product in a given state. If my Web site's shopping cart software were to pass the parameters, State=HI and Product=Cabbage (in people terms, "What is the sales tax rate on cabbage in Hawaii?"), the Web Service, GetRetailTax, will return 4%. For the parameters, State=WA and Product=Cabbage, RetailTax will return 0%, knowing that there is no sales tax in WA for food. In C#, the call would look something like this:

    TaxSite retailTax = new TaxSite();
   string statecode="HI";
   string productcode="cabbage";
   int taxRate = retailTax.GetRetailTax(statecode,productcode);

Now, GetRetailTax may itself need to call on other Web Services in order to satisfy your request. Perhaps the tax rates for certain products in certain states change so frequently that RetailTax needs to constantly access the state's Web Service for the latest rates. So, why wouldn't my Web site's shopping cart software just call each state's Web Service directly, rather than go through the "middle-man"? Because then my shopping cart software (ie, Me) would need to maintain the knowledge of how and where to get that information as opposed to "leaving it up to the experts".

This is how things would also work if we happened to know a person that is an expert at retail sales tax rates. This person would require the same bits of information to return the same bits of knowledge. I would pass the parameters vocally (speaking the phrase "What is the sales tax for cabbage in Hawaii?") or in writing in a language that this expert understands. The expert would accept this message either through his/her ears or eyes. The expert's brain will do some processing, ultimately issuing a series of commands to various parts of his/her body that result in my ears hearing "four percent", or perhaps my eyes seeing him display four fingers.

Note: Notice that we don't really care about how the human expert or the RetailTax Web Service arrives at the answer. We only care about the answer. The way the answer is arrived can change hourly for all we know. But the way we interface with the human expert of the Web Service remains constant. This abstraction is called "encapsulation". The process is encapsulated behind a the interface.

This sales tax scenario works well as long as the set of parameters required to fulfill the service is consistent for all cases. However, this may even work well if there are few exceptions. For example, let's say hypothetically that Hawaii needs to also know who you are in order to determine a sales tax rate. If you can be identified as a farmer in Hawaii, your tax rate may be lower. So, for Hawaii, the RetailTax Web Service would need to pass three paramters to Hawaii's Web Service instead of two like for the other 49 states. Making this accomodation wouldn't be too hard. It would be a matter of adding another parameter, for which no other state but Hawaii will utilize. Or, the host of GetRetailTax could expose multiple versions of GetRetailTax (overload GetRetailTax). This C# code illustrates this using an multiple versions of GetRetailTax:

   if (statecode == "HI")
   {
       taxRate = TaxSite.GetRetailTax(statecode,productcode,customerid);
   }
   else
   {
       taxRate = TaxSite.GetRetailTax(statecode,productcode); 
   }

Or, you could elect not to service customers in Hawaii (but that would still require at least a polite message).

So, what happens if every state decides to complicate their retail sales tax rules? The rules could even go down to the county level. They could be very different for different times of the year or under different social climates (natural disasters, time of war, etc). Would we create a separate version of GetRate (perhaps thousands) for every rule requiring a unique set of parameters? Kicking it up another dimension, what about all the other thousands of Web Services that exist? Wouldn't they potentially all require many different sets of parameters?

There would be no way to get around the mess of rules. However, there is a way to robustly encode the rules and robustly interface with the Web Services. That's the subject of the next section.

SCL Web Services

As stated above, SCL Web Services are Web Services except that instead of passing strictly specified parameters they pass SCL fragments. SCL fragments are SCL (Prolog-based) databases consisting of a set of facts and rules, but incomplete in themselves. This means they are intended to be merged with one or more other SCL fragments resulting in "workable knowledge"; enough facts and rules to answer questions.

Note: For a brief overview of SCL and Prolog, see my article, Introduction to SCL.

This part will be completed at a later time.