wws - Exact Search Appendix 1

Appendix 1 – A Purchasing Illustraion

The following is a highly detailed simulation of how wws might be used to perform purchases. It provides fictional characters, organizations, language games, and services to perform the simulation. A lot of detail is covered in the hope of making the example realistic and convincing,  and in the hope of illustrating the type of power and sophistication that could be achieved using wws web services. In particular, it was desired to show how a vast array of services of different types could work together to achieve a sophisticated result.

2.1 The Task

AusTech Engineering provides specialized engineering services to clients throughout the world. Jane Harris a department manager. She wants to buy 5 KimikoTech "T1R10" long life super high capacity ultra-heavy duty compressor plants for CO2 storage at energy production sites. She has a budget of $15,000,000.00 AUD.

KimikoTech produces T1R10's, but it does not sell them directly. It sell the technology and parts to expert engineering operations who assemble and resell the units.

Jane wants to buy these units using the in-house purchase order system called POSystem5.1. POSystem5.1 is one of the wws standards for placing purchase orders.  AusTech uses an off-the-shelf version with few local modifications.

AusTech's POSystem5.1 is actually a little old with POSystem8 having been released. In addition, rival purchase order language games have appeared on wws, which POSystem5.1 is partially compatible with when used with the additional services of a wws Interpreter Service. AusTech is biding their time before making a decision.

Purchase Order systems such as POSystem5.1 are used in a variety of ways. Sometimes there is a prior arrangement with a supplier and the system is simply used to place a purchase order. In this case generally no search will be involved, unless the supplier changes the wws location of their service. Other times a full global search will be performed, and a comparison of the results made to determine the best selection. In addition, sometimes a search will fully automate placing the purchase order without human intervention. Other times the order will be placed with a "Pending Approval" status. This will require a person to intervene and take the order to the last step of "Approved".

In our case, a search will be performed. Because of the amount of money involved the order will be placed with the order with a status of "Pending Final Approval". Jane will then review and approve or withdraw within 48 hours.

2.2 The Global Environment

A number of service providers would typically be involved in supporting a Purchase Order Search.

In our example they are listed in the following table.

2.3 The Local Environment

The following table shows the Search Agents in POSystem5.1’s local environment.

2.4 Search Characteristics

POSystem5.1 along with other Search Agents has the following search characteristics. It is:

·        “Imperative driven”,

·        “Peer Coordinated”,

·        “Interpreter Reliant”,

·        “Subscriber Financed”.

POSystem5.1 will also use other Search Agents who “use parallelism” We will explain these below.

2.4.1 Imperative Driven

What is meant by saying that the search is “imperative driven” is this. At the center of a Search Agent’s search strategy is a single generally multiple-term statement in a formal language such as predicate calculus called the “Search Model”. The Search Model serves as the model of what the outcome of the search should be. The Agent’s imperative or reason to be is to fill in the terms of this Search Model.

The idea is that the user will fill in some of the terms and then it is up to the search agent to find ways to fill in the rest. This will most often involve contacting an external Search Agent which will search wws to find Search Service Providers which can fill in the terms.

We can express this in predicate calculus as follows. In addition to the quantifiers (Ex), “some x”, and (Ax), “all x”, we have (Ux) for “unknown x” and “(Fx) for “free x”. A sentence can use all four types of quantifiers with (Ex) and (Ax) used to show logical relations between relational predicate terms, and (Ux) and (Fx) used to define predicate relations to be filled in. (Ux) indicates terms that must be filled in for the search to be successful, and (Fx) shows terms which can be filled in.

Very often, as in the case of a Purchase Order search, a Search Agent will return a number of alternative solutions to the Search Model.

2.4.2 Peer Coordinated

What is meant by “Peer Coordinated” is as follows. A Search Agent does not generally exist in isolation, but rather exists in a network of other Search Agents. Some of the peers of a Search Agent like POSystem5.1 will have an interest in the information the Search Agent is dealing in. Rather than programming the Search Agent to forward this information, we adopt a simple protocol where the peer Search Agents may ask for the information they want.

We can illustrate how the protocol works with reference to POSystem5.1 . At the beginning of each search a Search Agent like POSystem5.1 will contact its peer supervisor, Super01, and ask for a list of its peers. It will then contact each peer and ask it if the peer is interested in being informed as POSystem5.1 takes steps in the search it is about to perform. This will give the peer the opportunity to send questions to POSystem5.1.

If a peer is interested then POSystem5.1 will then contact its Search Security Agent, Security9, to determine what rights its peers have. These rights have two forms. First a peer will have rights to be informed about only certain relational terms in a solution. For instance, a peer located outside the local network will probably not have the right to access information expressed in the “UnitPrice(x)” relational term. Secondly a peer may have rights to interfere with a search. For instance, a peer responsible for budgeting, such as Budget10, may have the “StopVeto” right, where it exercises its veto right to stop a search; say if the conclusion of the search would blow the budget.

 2.4.3 Interpreter Reliant

What is meant by “Interpreter Dependent” is as follows. Different Search Agents will typically different versions of the same language game. These different versions may be earlier and later versions of the one product released by the one organization, or they may be different products for the same language game released by different companies.

Interpreter services provide bridges between different versions. If different signs have been different versions then the Interpreter may be able to provide mappings from one product to another.

In addition sometimes we will want to be able to have effective communication between Search Agents implementing different language games, and an Interpreter will be required for this. For example, a Search Security Service such as Security9 may send a message to a Search Agent such as POSystem5.1 not to share “financial information” with external agents. “FinancialInfomration(x)” may not be a relation that POSystem5.1 understands. In this case a Search Interpreter Service such as LAInterpret may be able to bridge the gap between Security9 and POSystem5.1 by presenting Security9’s restriction to POSystem5.1 in terms POSystem5.1 does understand.

For instance, LAInterpret may have an “Interpreter Module” Interpret20051 which provides the Union of the two languages Security9 and POSystem5.1 and has rules such as:

(For all x) (UnitPrice(x) or Discount(x) or GrossPrice(x) or NetPrice(x) or …) implies FinancialInformation(x).

Using this information, plus its knowledge of which languages contain which relations it can work out that to deliver to POSystem5.1 Security9’s prohibition against sharing financial information with external agents it should instruct POSystem5.1 not to share the terms UnitPrice(x), Discount(x), NetPrice(x) etc. It simply has to rewrite Secuity9’s sentence substituting these terms for the term FinancialInformation(x) in a suitable way.

Search Interpreter Services can also be agents for cohesion. Since they are in touch with the different ways in which languages are splintering they are well placed to make recommendations as to how to better integrate languages in future releases.

2.4.4 Subscriber Financed.

What is meant by saying that searches are “subscriber financed” is as follows. Very frequently in the course of a search a Search Agent may require the use of services provided by other parties.  Sometimes the other party would charge for its services.

For instance we have mentioned “Search Interpreter Services” which provide interpreter services between language games. We also have “Search Data Services” which provide empirical information used in searches. Such information might be the unique postal identifiers associated with addresses used in each country, basic tax information, independent corporate data such as annual profit, etc.

One model would be for a Search Agent performing a search for a client to present its client to the other party as the recipient for the service. The other party could then inquire with the client if it were willing to accept the charges for the search.

Another model would be for the Search Agent to be a “one stop shop” for services. It would cover all costs for its client and either charge its client a subscription or fee.

A fee for service using very small credit amounts may also be used.

2.5 Parallelism

We can illustrate why wws uses parallel searches as follows. The following shows a slice of a Search Classification Index used by one Search Agent, such as SearchCentral:

The index shows three main categories commerce, language, and science. It also shows six “main relations” buying, selling, translation, definition, calculation and explanation. These broadly correspond to six broad different language games.

The leafs of the tree are two different types of service. The “sa” services represent “Search Agent”. These can be used to perform a search. An “ss” entry represents a “Search Service”. These represent the end-points of the search who are the service providers – who provide the sale, translation, definition, calculation, explanation etc.

The point of a wws search is always to find the Search Service (ss) that you want. For instance, if you want to translate Chinese into another language then you need to locate a Chinese language translation service.

The challenge of wws is how to best perform such searches. Wws employs 1) formalized language structures, and 2) widespread take-up of the same symbols. This should result in simpler and more accurate searches. Probably only a small number of classification systems would need to emerge. However there is still room for variation.

Variation would occur since:

·        Users would supply information of varying levels of incompleteness.

·        Organizations would proffer competing classification systems.

·        Organizations would compete to attract Search Services to register with them.

·        Different heuristic strategies can be used to supplement searching using Search Classification Index.

If there is room for variations in Search Agents, then one way to optimize searches is to allow parallel searches.

2.6 Search Process

We now proceed with the search.

2.5.1 Search Inception

2.5.1.1 Choosing the Model

The search begins with Jane bringing up the POSystem5.1 screen. The screen displays a large number of fields and a number of different sections.

At austech POSystem5.1 is setup to show a model for travel and accommodation search. Jane quickly changes this by setting two parameters in the “Search Type” section type as follows:

·        Part Category:                          industrialEquipment

·        Value:                                       > $50,000.00 AUD

She also enters in the Product Identification section:

·        Manufacturer:                           KimikoTech

She then hits enter.

This information is sent to POSystem5.1. POSystem5.1 searches through its models and finds one which fits the parameters entered. This model in fact turns out to be one that could be applied to any product category. The real differentiator is the parameter > $50,000.00 AUD.

The model chosen for purchases > $50,000.00 AUD, does not contain the relation PurchaseStatus(x, “Approved”) as committing a transaction with status would obligate austech to honor it. There is too much money involved for austech to trust to a fully automated purchase. Rather the model contains the term PurchaseStaus(x, “PendingApproval”). This indicates to the supplier that there is no commitment on the part of the buyer. Once Jane has reviewed the purchase she may then issue a PurchaseStatus(x, “Approved”) and then austech is committed. The suppliers receiving the information of the purchase with PendingApproval status is still an important piece of information, as more than half of such transactions eventually receive Approved status.

2.5.1.2 Acquiring a Search Identifier

The next thing that POSystem5.1 does is acquire a Search Identifier. It can acquire this in advance of contacting its Search Engine with its search or at the time of contacting the Search Engine with its identifier. It chooses to acquire the Search Identifier in advance.

The Search Identifier in fact has three components. Firstly, it has a “primary identifier” generally used to refer to the search which consists in an arbitrary “long” integer. Secondly, it has a “date-time stamp” expressed to the millisecond using a long integer. Thirdly, it has a “time to live” value also expressed as a long integer which by default is 20 seconds.

POSystem5.1 needs the Search for 2 reasons. Firstly, it will want to refer to its search to its Search Agent and to its peer processes. The Search Identifier will assist in this.

Secondly, it needs the Search Identifier because of the way wws searches are performed. Frequently a wws search agent will be assigned to Search Agent such as SearchCentral who will in turn assign the search to other Search Agents. These Agents may in turn refer the search to other agents. Thus we have parallel searches and searches which may “cross over” on to each other or even loop. The Search Identifier is used to stop this. Wws adopts the protocol that if a Search Agent receives a search request with the same identifier as the one that it has already seen then it will not refer that search on any further but simply return an “AlreadySeen” code.

The date-time stamp is used in conjunction with the primary key to guarantee uniqueness. The “time to live” integer is used to tell Search agents how long they should keep information on “AlreadySeen” searches. “Time to live” can also be used by a Search Agent to determine when it can simply ignore a search and not even respond.

As explained above, the reason why wws uses parallel searches is simply because different Search Agents may have different Search Classification Indexes and search heuristics

2.5.1.3 Search Definition

The following table shows the basic relations in POSystem5.1’s search model for the present case.

2.5.1.3.1.1 Table Headings

The table contains the headings “Component”, “Agent”, “Assign”, and “Relations”.  “Component” simply provides a convenient grouping of relations.

“Agent” defines who is responsible to fill in the terms, either “self” if POSystem5.1 has to fill in the terms, “user” if the user needs to fill in the terms, or “external” if the external Search Service needs to fill in the terms. “peer” is another possible value not used here.

“Assign” identifies whether a group of relations needs to be filled in. This can change as the search progresses. “Relations” identifies the actual relations themselves that need to be filled in.

2.5.3.1.2 Terms Components

The basic job of POSystem5.1 is to traverse the Terms section and arrange for these terms to be filled in. It will either fill them in itself, or refer back to the user, or assign the job to the external Search Service.

There three different kinds of terms shown. Those with an existential quantifier (Ex) are already filled in. Those with an “unknown quantifier” (Ux) need to be filled in. Those with a “free quantifier” are optional. We use two ranges of variables for arguments. We have “abbreviations” a...p, and “assignments” q..z.

For instance in “Ref(e, ”wws.untrade.com*commerce.measures”)” the relation is indicating that the variable “e” is going to be used an abbreviation for ”wws.untrade.com*commerce.measures”. Then, for instance, “UOM(y, r, e)” can be expanded to UOM(y, r, “wws.untrade.com*commerce.measures”).

On the other hand a variable such a y in “Part(y, “wws.intEngineers*partIndex”)” represents a variable we want assigned in order to progress the search.

2.5.3.1.3 Protocol Components

The “Protocol” section defines frequently used abbreviations. For instance, “Currency (a, “AUD”, “wws.untrade.com*currency”)” indicates that the variable “a” is being used as an abbreviation for the symbol “AUD” as this symbol is specified by the wws reference “wws.untrade.com*currency”. The abbreviation is then used in relations such as UnitPrice(), Tax() etc to specify that the relation must be specified in Australian dollars.

2.5.3.1.4 Requested Service Components

The “Requested Service” section is a key component. The mandatory Service() relation is called the “Key Search Term” and more than anything else it defines the service being sought. It defines the fundamental service sought from the list of services that can be requested as specified by reference wws.wws.com*service. The value it has specifies a broad category of language game where member services have broadly similar purposes.

The Key Search Term will be used by external search agents to select categories in a Search Classification Index such as the one illustrated in section 2.5. When a matching category is found services listed under this category can be questioned to determine whether or not they are able to provide the service requested in both general and specific terms.

In the worst case a Search Agent would simply navigate its Search Classification Index and test all the Search Services that match the Key Search Term to see if they can provide the service requested. This would result in an enormous number of unnecessary requests. So in addition to the Key Search Term there are other search heuristics.

For example, POSystem5.1 also offers the “Classification” as a search heuristic. Some Search Agents would use this relation, and others would ignore it. . In a similar way some Search Agents such as SearchCentral can use other terms defined by POSystem5.1 such as PartCategory() in searching their Search Category Index. This requires that the Search Category Index used by Search Central be build with categories such as “wws.milanenginfo*part.category” in mind.

2.5.3.1.6 BuyStatus

The BuyStatus() is used to indicate to interested parties the level of commitment of the buyer to the purchase. Some values are “QuoteOnly”, “PendingApproval”, and “Approved”. The current model was selected with BuyStatus() set to “PendingApproval” since the purchase value > $50,000.00 AUD.

2.5.3.1.7 Search Stage

The SearchStage() is used to indicate to interest at what step the search has progressed to. Some values are “begin”, “beforeCommit”, “afterCommit”. SearchStatus() is initialized to “begin”.

2.5.3.1.8 Search Status

 Search status is used to indicate how the search is progressing and to control the progress of the search. Values are “ok”, “cancel”, “defer”, “halt”, “success”, “fail”, “wait”,  “continue”, “extend”, “partial” . SearchStatus() is initialized to “ok”.

2.5.3.1.8 Search Status() is used to indicate how the sear

2.5.3.1.7 Other Components

The remaining relations define terms that need to be filled in for the search to be successful.

2.5.3.1.8 Relations

Relations have the general form R( y, z, c1, …, cn , s). “R” is the name of the relation. “y” is the subject of the relation. “z” is an attribute – a value we assign to y “under the current relation”. “c1…cn” are additional parameters, often specifying “protocols” as specified above. “s” is a “remote service reference”.

For instance, in the Parts component section we introduce the variable “y” in the relation “Part(y)”. y is the “subject” of this relation, and in fact is the subject of all remaining relations. y is “the thing” we want to specify, and we specify it by including it in multiple relations.

“Part(y, y1, “wws.intEngineers*part”)” is an example of one of the relations y occurs in. In this relation y1 is the attribute variable which needs to be assigned a variable for the reference to be complete. For example, “Part(y, “T1R10”, “wws.intEngineers*part”)” shows a completed relation where y is assigned the attribute “T1R10” under the relation “Part()” as this relation is specified by the “remote service reference” “wws.intEngineers*part”. This is the same as saying “y is the Part T1R10 as specified by the service wws.intEngineers*part.

2.5.3.1.9 Remote Service References

“wws.intEngineers*part” is a “wws remote service reference”. “wws.intEngineers” is called the “service host” and “part” is called the “service designator”. A service designator such as “part” would typically provide both a wws “Key Search Term” plus a “language game designator”.

Because wws.intEngineers*part designates a service, issuing “wws.intEngineers*part” via your browser or under program control would result in a “Service Available” response.

Because “part” designates a “language game” it sets a set of expectations. A language game provides a loose vocabulary and a loose set of rules suited to a common purpose. There will be a range of language games specified as “part” language games. They will differ from one another. But to use Wittgenstein’s terminology they will all bear a certain “family resemblance”. There similarity rests in their all sharing a common purpose – in our case, to provide information about parts.

For example, a “part language game” might reasonably be thought to provide the following:

·        Part Identification – Part Number or UCP.

·        Part Manufacturer – the maker of the part.

·        Part Description – a basic description of the part.

·        Part Long Description – a more extensive description of the part.

·        Part Specification – specification with reference to some standard

·        Part Accreditation – accreditation according to some standard.

·        Part Compatibles – parts which may be substituted for the part.

·        Part Assemblies – assemblies in which the part features.

·        Part Sub-assembly – the parts which make up the part.

·        Part Export Restrictions – any export restrictions that apply.

There will of course be extraordinary variation in the various implementations. However, there will be some overlap. For instance, it is likely that a practice involving parts will acknowledge some form of part identification and some form of part manufacturer identification.

There will be some overlap in terms of the relations used, independently of whether or not they use the same signs.  It could be productive to exploit this overlap. In addition, recognizing a concept of “part” which is used in the part language game could be useful in formulating Search Classification Indexes.

2.5.3.1.10 Using Remote Service References

In the current context a relation such as “Part(y, y1, “wws.intEngineers*part”)” defines a relation you will be able to use with the remote service. So if “Part(y, y1, “wws.intEngineers*part”)” is a valid relation then you will be able to send “Part(y,y1)” to the service wws.intEngineers*part and be understood. For example if  “Part(y, y1, “wws.intEngineers*part”)” is a valid relation and “Manufacturer(x, x1, “wws.intEngineers*part”) is a valid relation then you should be able to send to the service wws.intEngineers*part the question

                        (Ex)(Uy)(Part(x, “T1R10”) & Manufacturer(x,y))

and get the response

                        (Ex)(Part(x,”T1R10”) & Manufacturer(x, “KimikoTech”))

Note, language games can provide more than naming services. They can also provide services such as calculation. For instance if wws.hkfin.com*commerce.price was a remote service for pricing then we should be able to send it

(Ex)(Uy)(UnitPrice(x, $10.00) & Quantity (20) & Tax(x, 25.0%) & Discount(x, 25.0%) & TotalToPay(x,y)

and expect the answer

(Ex)(UnitPrice(x, $10.00) & Quantity (20) & Tax(x, 25.0%) & Discount(x, 10.0%) & TotalToPay(x, $225.00)

Note also that the simplicity of this example neither precludes it being correct in a vast range of causes or from us building up more complicated cases. These are two of the advantages of language games.

2.5.3.1.11 Remote Service References – the Key to wws

If wws had a marketing slogan then it might be “Use a remote reference service and you will be understood.” Remote Service References are as important to wws as hyperlinks are to www.

In wws we try as far as possible not to define anything locally, but to always use remote service references.

From a technical point of view, what we are saying is that in the ideal case where there is only one definition of a thing such as a part or a price calculation. Then if other parties use that definition as well then we will be successful in referring to the same part and we will be successful in using the same price calculation.

From a conceptual point of view what we are trying to do is establish the widespread use of symbols rather than signs or “Strings”. We can say that a symbol just is a sign with widespread currency across groups of people, and across contexts. If we use symbols in our construction of applications then it as if we are in contact with each other, part of the same project. Our systems will be interoperable. More about this later.

2.5.1.4 Defining the Part

To begin the search process POSystem5.1 goes to the Terms section of its model and starts looking for “unknown terms” stepping through the various component categories.

It finds variables q, z, y1, y2 in the Part section are unknown. There are a number of things that it can do here. However, because Jane has already given it the value “KimikoTech” for Manufacturer it starts with the “phrase”

(Manufacturer(z1, “wws.milanenginfo.com*manufacturer) & wwsref(z1, z2) & Part(y, y2,z2)

This specifies that a part can be specified by giving the Manufacturer, the Manufactuer’s wws remote service site, and the attribute value in that remote service site.

So POSystem5.1 first forwards the sentence

(Ex)(Uy)Manufacturer(x, “KimoTech”, “wws.milanenginfo.com*manufacturer) & wwsref(x,y)

to SearchCentral who in turn forwards it on to wws.milanenginf.com. wws.milanenginfo.com returns the sentence

(Ex)(Uy)Manufacturer(x, “KimikoTech”, “wws.milanenginfo.com*manufacturer) & wwsref(x,”wws.kimikotech.com”)

This validates that “KimikoTech” is in fact a valid manufacturer name and it gives POSystem5.1 a remote service reference which it can use to determine the part name.

So POSystem5.1 writes the sentence

(Ux)wwsref(x, “part”, “wws.kimikotech.com”)

It wants to know if KimikoTech has a remote service reference for the “part” language game. KimikoTech responds with the sentence

wwsref(“wws.kimikotech.com*part”, ”part”, “wws.kimikotech.com”)

which verifies that it does have an implementation of the “part” language game and that this is at “wws.kimikotech.com*part”.

So POSystem5.1 writes the sentence

(Ex)(Uy)(Manufacturer(x, “KimikoTech”) & Part(x, y, “wws.kimikotech.com*part”)

and forwards it on to SearchCentral who forwards it to KimikoTech.

So now KimikoTech has a dilemma. It is being asked for a part which it manufactures and which it provides in provides a remote reference for. The trouble is that there are thousands of such sites. wws “best practice” stipulates that a Search Service should narrow its answers to as few references as possible which still cover all cases. So KimikoTech returns the answer

(Ex)(Uv)(Uy)(Manufacturer(x, “KimikoTech”) & PartCategory(x, v, “wws.milanenginfo*part.category”) & Part(x, y, “wws.kimikotech.com*part”)

It wants to know the “PartCategory()”. POSystem5.1 receives this question and needs to determine what to do with it. It sees that Jane has already specified the PartCategory as “industrialEquipment”. So it responds:

(Ex)(Uy)(Manufacturer(x, “KimikoTech”) & PartCategory(x, “industrialEquipment”, “wws.milanenginfo*part.category”) & Part(x, y, “wws.kimikotech.com*part”)

Since both austech and KimikoTech use the “wws.milanenginfo*part.category” remote reference service for specifying PartCategory values we can be confident that Jane’s specification will be understood without the need for an Interpreter such as LAInterpret.

KimikoTech uses the PartCategory() to narrow the search but still comes back with hundreds of values. So in reply it writes the sentence

(Ex)(Uw)(Uy)(Manufacturer(x, “KimikoTech”) & PartCategory(x, “industrialEquipment”, “wws.milanenginfo*part.category”) & PartType(y, w, “wws.milanenginfo*part.category.type”) & Part(x, y, “wws.kimikotech.com*part”)

POSystem5.1 receives the reply and determines that it is being prompted for a value for PartType(). Reviewing its model it determines that PartType() can be determined by the user. So it prompts Jane for a value for PartType().

Jane selects “compressors” and hits enter. Again since both austech and KimikoTech use the “wws.milanenginfo*part.category.type” for PartType()  remote reference service we can be confident that Jane’s answer will be understood. So POSystem5.1 simply writes the sentence

(Ex)(Uy)(Manufacturer(x, “KimikoTech”) & PartCategory(x, “industrialEquipment”, “wws.milanenginfo*part.category”) & PartType(y, “compressors”, “wws.milanenginfo*part.category.type”) & Part(x, y, “wws.kimikotech.com*part”)

KimikoTech receives the sentence and while there is still more than one possible anwer it cannot narrow the search any further. So it issues its return answer

(Ex)(Manufacturer(x, “KimikoTech”) & PartCategory(x, “industrialEquipment”, “wws.milanenginfo*part.category”) & PartType(y, “compressors”, “wws.milanenginfo*part.category.type”) & (Part(x, “CI10”, “wws.kimikotech.com*part”) or Part(x, “CI15”, “wws.kimikotech.com*part”) or  Part(x, “CI20”, “wws.kimikotech.com*part”) or Part(x, “CI100”, “wws.kimikotech.com*part”) or Part(x, “T1R10”, “wws.kimikotech.com*part”))

POSystem now has a number of possible answers for part: CI10, CI15, CI20, CI100 or T1R10. It cannot narrow the search any further so it asks Jane to make a selection. Jane easily recognizes the part she wants, selects T1R10, and with that the part is determined.

2.5.1.5 Defining Other User Defined Attributes

Now POSystem5.1 proceeds with the determination of the remaining values.

Firstly, it prompts Jane for Quantity() and UOM() which she assigns 5 and 1 to respectively.

Next it skips the Price Definition component. It will return to this when all the variables which can be assigned by itself or the user are assigned.

So it proceeds to the  Delivery Details component and prompts Jane for DeliveryDate(), Address(), and Transporter(). Jane is not interested in specifying these at the moment so she goes to the Delivery Details section of her screen and unchecks the checkbox “Assign Delivery Details” and hits enter. POSystem5.1 receives Jane’s message and sets Assign to “N” for the Delivery Details component and will not issue any more questions about Delivery Details.

So it now returns to the Price Definition section. Since all the variables in this section are “external” it can only proceed by commencing an external search. So it takes steps to perform an external search.

2.5.1.6 Notifying Peers

2.5.1.6.1 Determining Peer Rights

As mentioned in section 2.4.2 POSystem5.1 searches are “peer coordinated”. Its peers have rights to ask questions about relations in searches, and some even have the right to stop a search by sending the “StopVeto” signal.

So before beginning the search POSystem5.1 contacts its Search Supervisor, Super01, and finds out who its peers are. It then contacts each peer to see if they are interested in its search. Its internal and external peers are AR2006, Budget10, IntSearch, LegalSoft, SalesMeasure, HKFinance.

Of these AR2006 and IntSearch are not interested in its search at all.

POSystem5.1 then forwards the list of interested peers to Secure9 to determine their rights. The intereseted peers are assigned the following rights.

Sales measure has been assigned the rights to all relations except “other party” details. That is Secure9 has sent POSystem5.1 the sentence

(Ex)(Ey)(Az)(SearchIdentifier(x, “99988334”, “wws.ap.wws.com”) & SearchAgent(y, “wws.salesmeasure.com”, “wws.wws.com”) & OtherParty(z, “wws.usecure.com*secure9”) -> Exclude(z, “wws.usecure.com*secure9”)

What this is saying is that “with respect to the current search, with respect to the Search Agent, if something z is an OtherPary then it is Excluded”. POSystem5.1 does not know what this means. But it knows it needs to find a way to make the sentence true.

So via SearchCentral it sends a request to LAInterpret to find a solution to the following sentence

(Ax)(Uu)(OtherParty(x, “wws.usecure.com*secure9”) ->  Translate(x, u, “wws.posearch.com*posystem5.1”)

That is it wants to know “all the instances of u such that for any instance of x, x is a in instance of OtherParty() in wws.usecure.com*secure9 and x is translated by u in “posearch.com*posystem5.1”. LAInterpret can handle the mapping between the two languages and replies

(Ax)(Au)(OtherParty(x, “wws.usecure.com*secure9”) & Translate(x, u, “wws.posearch.com*posystem5.1”) -> Supplier(u, “wws.posearch.com*posystem5.1”)

LAInterpret is replying that the Supplier() relation in wws.posearch.com*posystem5.1 satisfies the OtherParty() relation in wws.usecure.com*secure9.

In the same fashion POSystem5.1 finds out what the Exclude() relation means in wws.usecure.com*secure9. It turns out that it means the same in wws.posearch.com*posystem5.1 as it does in wws.usecure.com*secure9. So the bottom line in POSystem5.1 ends up with the condition

(Ex)(Ey)(Az)(SearchIdentifier(x, “99988334”, “wws.ap.wws.com”) & SearchAgent(y, “wws.salesmeasure.com”, “wws.wws.com”) & Supplier(z, “wws.posearch.com*posystem5.1”) -> Exclude(z, “wws.posearch.com*posystem5.1”)

which it will have to adhere to throughout the search.

2.5.1.6.1 Signalling Peers

So since we now know the peer rights and are at the first step of the search POSystem5.1 sends each of its peers the sentence

(Ex)(SearchIdentifier(x, “99988334”,  “wws.ap.wws.com”) & SearchStage(x, "begin", “wws.wws.com*service.search”))

However, since we are only at the beginning stage the peers are not really interested and so simply send the signal

(Ex)(SearchIdentifier(x, “99988334”, “wws.ap.wws.com”) & SearchStatus(x, "continue", “wws.wws.com*service.search”))

2.5.2 Ready to go – Commencing the Search

Now POSystem5.1 has enough information to begin the search and it has informed its peers. So it starts the search in earnest.

So it sends SearchCentral  a slightly edited version of its model

2.5.3 Performing  Search Request Request

SearchCentral needs to determine what to do with the model.

The requested Service() is “sell” as specified by “wws.wws.com*service”. “Sell” thus constitutes the “Key Search Term” and the name of the language game which it has to perform. It also has the relation “Classification()” with value “commerce” as specified by wws.com*classification.

SearchCentral’s Search Classification Index is built around these two concepts Service() and Classication(). So it searches through its index to come up with the list of services:

·        ss: wws.allmakets.com

·        ss: wws.hyuan.sales.com

·        ss: wws.patriziatech.com

·        ss: aruntech.com

·        ss: alisiaenergy.com

·        sa: wws.posearch.com

·        sa: wws.bizsearch.com

·        sa: wws.bestsearch.com

Before proceeding any further it asks POSystem5.1 if it uses a “Search Guide Service”, a service that keeps lists of recommended and non-recommended sites. POSystem5.1 asks Super01 who responds that austech uses wws.searchguide.com.

So SearchCentral asks wws.searchguide.com whether all the items in the list are ok. Wws.searchguide.com responds that they are except for wws.allmakets.com. So wws.allmarkets.com is removed from the list.

SearchCentral needs to find out who can provide the service. So it edits the model, has it translated into the language it knows, “wws.posearch.com*posystem10”, and sends a copy of the model to each of Search Services and Search Agents.

2.5.3 Responding to the Search Request

In order to respond to the Search request each queried Search Service will need to do a number of things. Firstly, it will need to translate the model into its own “sell” language game implementation. Next it will have to use its capabilities for peer communication, database search, etc to assign values to the “unknown” variables. Then it will need to translate the model back to the “sell” language game of its requestor. This may require the use of Interpreter Services.

2.4.4 Collecting Search Results

When the queried Search Services return their responses a lot of things happen now.

Firstly, wws.hyuan.sales.com comes back with the request to extend the SearchFinalisationDate() to the next day. This is common for processes involving people and HyuanSales is a selling organization which uses its extensive network of contacts to source products. So SearchCentral forwards this question to POSysem5.1 who forwards it to Jane, and the SearchFinalisationDate() is extended to the next day. HyanSales will used the BuyerAddress() to send its results to wws.austech.com.

wws.alisiaenergy.com comes back with the question whether or not “used” equipment is ok. So SearchCentral sends this question to POSystem5.1 who asks Jane who responds that only new equipment is required. This information is forwarded back to wws.alisiaenergy.com who then responds with the model to include SearchStatus(y, “fail”, “wws.wws.com*service.status”), and wws.alisiaenergy.com leaves the search.

wws.posearch.com comes back with a model with a model with the name of a new Supplier, RodneyTech, who can fill meet the search conditions.

wws.bizsearch.com only comes back with models featuring the same Search Services as those SearchCentral already know about.

wws.bestsearch.com tries to use special techniques to optimize but does not come up with any Search Services.

Patriziatech and ArunTech both come back with models showing SearchStatus(y, “ok”, “wws.wws.com*service.status”). So Patriziatech, ArunTech, and RodneyTech all can sell T1R10s.

Therefore,  SearchCentral resends them the model with the additional components for Buyer and Quantity filled in, and the additional component for Price to be filled in. Each party returns a copy of the model with all fields filled in.

2.5.3 Initial Results

The following table shows the model returned by Patriziatech.

SearchCentral notes that the status has changed from “ok” to “partial”. Closer inspection shows that the Quantity() has been changed from 2 to 5.

So SearchCentral sends POSystem5.1 a question as to whether or not a Quantity() of 2 is ok for the current search. POSystem5.1 has a policy of allowing “split orders” so it responds that it is ok.

In addition note that the models have been returned from the queried Search Services using the protocols of the queried service. For instance, Patriziatech uses the Italian language and EUROs in its transactions.  SearchCentral will have to have these translated into the protocols of its client, POSystem5.1 at wws.austech.com.

wws.alllanguages.com provides a word by word translation service, and SearchCentral uses this to translate Italian to English.

SearchCentral finds out from POSystem5.1 that its banking service is provided by wws.mango.bank and SearchCentral has wws.mango.bank perform the currency conversion. This also constitutes an undertaking from wws.mango.bank that it will  perform the currency conversion  at the agreed rate come invoice time.

2.5.4 Initial Results and Selection

POSystem5.1 now has 3 models for the purchase of the T1R10 it could use. It needs to decide which one(s) to use. So it forwards its results to wws.commercedata.com. CommerceData is an expert in applying commercial rules to commercial data and can help decide the best choices to make. There being no other determining factor CommerceData uses TotalPrice() as the determinant. It can use the information sent to it to determine TotalPrice().  It thus assign 2 Units to Patriziatech at $2,000,555.00 AUD, 3 units to ArunTech at $2,100.030.00 AUD and 0 units to RodneyTech at $2,103,990.00.

So now POSystem5.1 is ready to commit. So before it does so it sends its peers the signal

SearchStage(y, “precommit”, “wws.wws.com*service.search”)

2.5.4 Preparing to Commit – Peer Questions

This time some of its peers are interested.

LegalSoft does not know anything about purchasing but it does know that it had better have a proper legal identifier for any entity with which it is involved in a financial tranaction. So it sends POSystem5.1 the instruction

SearchStatus(y, “wait”, “wws.wws.com*service.search”)

and then the question

(Ex) SearchIdentifier(x, “99988334”,”wws.ap.wws.com”) & Service(x, “financial transaction”, “wws.wws.com*service)

It wants to know whether POSystem5.1’s search is a financial transaction.

POSystem5.1 does not know what this means so it forwards sentence to SearchCentral inquiring whether its “buy” transaction is a financial transaction. This is forwarded to SearchCentral who passes it  on to wws.wws.com*service who returns the signal that a “buy” is a financial transaction.

So now LegalSoft inquires with wws.LegalSoftOnline.com*companies whether or not Patriziatech and ArunTech are legally recognized companies. They are, so LegalSoft issues POSystem5.1 with the message

SearchStatus(y, “continue”, “wws.wws.com*service.search”)

Budet10 also issues a “Wait” instruction. It wants to know whether or not the transaction is a debit or a credit, and whether or not the transaction would blow the budget. It is told that the transaction is  $10,000.00 TotalPrice(). This is inside the budget so Budget10 issues the “Continue” instruction.

2.5.7 Commit

So now POSystem5.1 can commit. It modifies the model of Patriziatech and ArunTech to show the  value “commit” for the SearchStage() . It  modifies RodneyTech’s model to show the value  “cancel” for SearchStage().  It sends each model to SearchCentral who forwards them on to the relevant Search Services.  Because these are financial transactions SearchCentral also sends copies to wws.mangobank.com and wws.securetrans.com.

Patriziatech and ArunTech both respond with the signal

SearchStage(y, “acceptCommit”, “wws.wws.com*service.search”)

and with this the transaction is commited. So POSystem5.1 sends to its peers the signal

SearchStage(y, “postCommit”, “wws.wws.com*service.search”)

 2.5.8 Post Commit – Market Research and Financial Reporting

www.hkfin.com and www.salesmeasure.com are both interested in different details of the transaction. So when asked POSystem5.1 sends the details asked for to them, taking special note not to send any “other party” data to www.salesmeasure.com.

2.5.10 Post Commit Review

Even though there is a lot of detail in our search we believe that it can be seen to be quite simple. Each individual step is  generally simple using a simple language game of request and response to get the results it needs. The whole adds up the a sophisticated service. The development of a service increases the potential of services that are its client.