wws - Exact Search
A System Proposal
Gerard McGovern 26/Feb/2006
1) Introduction
The objective of this document is to present a slightly different vision of how the web could work.
The www (world wide web) provides very numerous servers which respond to requests with Pages. These pages are the unit of meaning and they typically constitute complex semantic objects. These Pages may be indexed by Search Engines. Users can perform searches by submitting their searches to the search engines. The value of such searches are limited. Typically a lot of irrelevant information is brought back, and often the information you want is hidden by all the irrelevant information.
We imagine a different system, wws (world wide search). This system would provide multiple servers supplying services where these services essentially involve providing simple answers to simple questions. Instead of searching of Pages, this system searches over Statements. Such as Statement can be expressed in Predicate Calculus in such forms as P(x), R(x,y), S(a,b,c) etc.
Note that this paper covers much the same territory as the “semantic web”. See for example Fensel[2003]. It seems that the semantic web attempts to leverage the concept of “ontology”. This is a very different path than the path we wish to follow. If fact want to put up the competitor concept of “language game”. See for example Wittgenstein[1953]. However, without being familiar with the details of the semantic web research it is not possible to rule out our having reinvented the rule. If we have reinvented the wheel, then please note that this was not intentional
As a simplified illustration of the sort of search we envisage, a search might be a request such as Translate("English", "Japanese", "airport", ?) (translate the English word "airport" into the equivalent Japanese word) to which the reply might be Translate("Engish", "Japanese", "airport", 'ku-ko") (the Japanese word for "airport" is "ku-ko").
So wws searches are not provided by searching over Pages. Rather searches are performed over simple Statements such as the above. In the scheme the wws servers provide search services, and search engines operate by handing off the searches to the wws servers and then processing the results.
The primary benefit of this scheme is that it allows us to successfully perform "exact searches". We can give an approximate definition of exact searches as follows:
An “exact search” is a search featuring a number of terms where what is sought is a definition, explanation, translation, calculation or some other function of the terms such that the result is definitive, complete, authoritative, and optimally singular.
The real hallmark of an exact search is that the result returned is a function of just the terms in the search and not to the terms in the search plus other terms.
Examples of exact searches include questions such as the following:
However, we might also include questions such as the following amongst exact searches:
www does not handle searches like these well. It was not designed to handle searches such as these. The unit of meaning in the www context is the Page. Pages are designed in the first instance to facilitate human communication and information sharing. There content is not regimented in such a way as to facilitate machine processing. Machines could use such simple structures, but humans do not need them. In any case, Pages address semantically far more complex topics than those illustrated above.
Moreover, key word searches really constitute a "best guess" using key words as clues as to where you might find pages that have the content you are after. Since www has Pages as its unit of meaning, and since performs searches using a "best guess" approach, there is no surprise that it does not handle exact searches well.
wws on the other hand can be designed with the primary goal of facilitating exact searches. wws would constitute a domain of simple relational statements. As a very rough first approximation it might contain statements like these:
So wws can be expected to perform better than www in performing exact searches. If this was all there was to it then we might not want to proceed any further since there is clearly a great deal of additional work in supporting exact searches. However, there may be a lot more to it. Adopting an "exact search paradigm" may provide far greater benefits than is indicated by the examples we have covered thus far.
The key advantage of an "exact search paradigm" may be that it provides the ideal paradigm for building web services.
The reason for this is that if we employ simple well-defined relations and conjunctions of relations in performing searches and exchanging information then this provides a paradigm for very many parties contributing the execution of web services and this will promote the power of web services.
Simple well-defined relations and conjunctions of relations are something many different parties with different roles and specializations can understand and also use to make their contributions. This allows many different aspects of a transaction to be outsourced to different experts in different areas.
For example, in order to perform a world-wide search and place an order for a product a company needs to know what product it wants to order, how much it is willing to pay and where it wants it delivered to. However, it should not have to have a very high level of expertise in product identification, taxation and price structures, and exactly defined delivery points.
While it needs to be able to unambiguously identify the product it wants it does not need to be an overall expert in product identification. If it can supply the manufacturer and model, a third party can supply the part number. If there are compatible parts by the same or different suppliers it would be desirable if the company did not have to be expert in this area, but could still benefit from this information. This can be done if a third party supplies this expertise. Similarly, if a company wants to buy a product from another company in another region then it needs to know how much it needs to pay, but it need not know the taxation regime in that region. Pricing and taxation can be handled by a third party expert. Similarly, a company needs to know where it wants products delivered to, but it need not be an expert on different systems of "Delivery Point Identification". This can again can be usefully referred to other experts.
The point is simply that web services paradigm that leverage the exact search paradigm are able to leverage simple unambiguous services. The questions and answers in each case are simple and well-defined. However, a web service can leverage a great number of these simple services with the result that the web service can provide sophisticated functionality.
Exact searches would be somewhat similar but not the same as exposing and consolidating relational databases over the web.
3) wws Abstract Model
The wws abstract model has the following components:
· remote service relations
· remote services
· language games
· search classification indexes
· search interpreter services
· Search Services and Search Agents
wws determines a set of practices which when applied together hopefully constitute a successful model for utilizing web services.
3.1 Remote Service Relations
The first element of wws is a “remote service relation”.
The relation
Part(x, “T1R10”, “wws.kimikotech.com*part”)
illustrates a “remote service relation”.
A “remote service relation” can be thought of as a type of RDF. See Fensel[2003]. It is a type of RDF where the resource is a service.
The relation is written in a loose form of “predicate calculus”. The relation can be read “x is the Part with the value “T1R10” as specified by the remote service “wws.kimikotech.com*part”.
In this remote service relation “wws.kimikotech.com*part” is a “remote service identifier”. “wws.kimikotech.com” is the “service host” and “part” is the “service type”.
A remote service reference can be used to designate an object such as a part, organization, person, animal, mineral or other “thing”. But it can also be used to specify a function such as
TotalPrice(x, unitPrice, quantity, tax)
The primary use of a remote service reference is to define a reference which is independent of the local context. This allows processes which share these references to interoperate.
For example, if a 100 different processes all use the remote reference
Part(x, “T1R10”, “wws.kimikotech.com*part”)
for a particular piece of machinery t then those processors can be all “interoperable with respect to this specific ‘thing’ t”.
For instance, if processes A and B work together and both use this remote reference then we can be confident that they can refer to “the same thing” t. Then if process which may never have contacted A and B before also uses this remote reference, then C too can join in the processing with A and B and we can be entirely confident that they can refer to the “same thing” t.
Further allow that the remote service reference service type “part” designates a “language game” L which is associated with a set of relations R1, R2, …, R3 and that these express the relations in which t can occur. Also allow that 1) the remote service “wws.kimikotech.com*part” provides an implementation of L and 2) that A, B, and C implement some or all of L, then A, B, and C will be highly interoperable with respect certain relations in L which can be applied to t.
3.2 Remote Services
A remote service is a service that has an IP address and port and responds to requests. For instance, if we were to type into our browser
we might get the response “Part service available”.
Further if a remote service relation such as
Part(x, “T1R10”, “wws.kimikotech.com*part”)
is a correct remote reference then the remote reference service wws.kimikotech.com*part provides a service which incorporates the relation Part(subject, value). In other words we could send wws.kimikotech.com*part the relation Part(subject, value) and be understood. See the illustrations below.
3.3 Remote Service Types
“Remote Service Types” such a “part” in “wws.kimikotech.com*part” play in three different roles.
Firstly, as we have seen, they are used part of “remote service identifiers” to identify “remote services.
Secondly they become strongly associated with “language games” which are used to define them. By virtue of this fact associated with these concepts.
Thirdly they serve as service locators in search classification indexes.
We will illustrate these later points below.
3.4 Language Games
The concept of “language game” is used in the philosophical writings of Ludwig Wittgenstein. See especially Wittgenstein[1953].
As we see it, “language game” is primarily introduced to help us explain just what the meaning of a symbol rests in. “Meaning is use” is the central tenet. That is, the meaning of a symbol is its use in a language game where a language game is a set of practices. This is an alternative to other theories which usually define meanings as some form of special object.
For example, consider the case of a person who has a dog where the dog has trained its master well. Whenever it wants to go outside the dog goes and stands by the door with its head pointing to the door and barks once or twice. The person opens the door and the dog goes out.
This is a language game. It is not cause and effect. The dog uses its body to send a message. The message gets through, the door is opened, and the language game is a success. You could say the dogs positioning itself by the door is its symbol for “I want to go outside”. What symbol is that? We could try to explain the symbol with reference to special meaning objects. Or we could try to explain the symbol by just recounting the practice. This second option is to invoke “language games”.
Perhaps, the dog’s symbol is rather limited. We have other ones. Take the symbol of a “part”. You can use this symbol with the plumber, electrician, computer dealer, auto mechanic, retailer and very many others. You can use it in aeronautical engineering, bicycle maintenance, model airplane building, sales, doll house construction and very many other contexts. And you can do all this without invoking “special meaning objects”.
“Of what conceivable interest is this to IT or the web?” you might ask. The answer is “If we want to have computer systems which emulate the power of human symbol usage, then we should use language games.” In particular, we should emulate the practices we observe in language games.
How do we do this? Firstly, there are some rules we can follow in the attempt to emulate human language. Some of these rules are:
1. Use the same sign as a common symbol in multiple contexts where this makes sense.
2. Promote the use of symbols singularly, or in combinations with one or two symbols, or in combination with many symbols. Don’t just rigidly define one context for a symbol, which usually turns out to be a highly complex context tailored for one limited purpose. Instead give the option to allow communication to occur using numerous small interchanges which build on each other to build up a more complete picture.
3. Don’t invent a new sign every time you want to do something a little different. Try to use one that has common currency and is a well known symbol.
4. Don’t do anything to hinder the free mixing of symbols from different language games. Instead try to promote the use of the same symbols across as many contexts as possible, and in new unforeseen contexts. In particular, don’t rigidly define the context of a symbol by sticking a name space identifier in front of it. This does not encourage reuse. Only use a name space identifier if there is in fact a collision, and only use it on the symbol which has the lesser currency. Real symbols do not generally belong to a defined name space. We are free to use them in new contexts in new and surprising ways.
5. Try to get everyone to use the same symbols. An organization could define a set that we can start with.
6. If all else fails, get an interpreter.
Secondly, given the need computer systems have for regimented language, we can formulate our language games in a regimented language such as predicate calculus and maybe attempt to implement our systems using this.
3.5 A Sample Language Game
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.
So we would define relations to stand for these.
But there are objections to consider.
This “part” language game is not very sophisticated. However, it is reasonable to believe we can come up with something that really is useful for a very large group of people and really is useful over a very broad range of contexts, and can be extended. To define a “parts” language game we would consider a vast range of contexts which featured “parts” and try to draw out how they used “parts” in ways which were common.
This “part” language game is just one of the very many language games we could come up with for parts. Of course, it is, but we know there will be significant overlap between them, and this overlap is what we want. For instance, most will have a concept of “manufacturer”.
Where there is a lot of overlap but the signs are different then we can ask an interpreter to interpret. Just in the same way as English and Italian speakers can ask interpreters to interpret the words “part” and “parte”.
Some of these relations are not useful in my context. They don’t have to be. Just use the ones you want. One of advantages of human languages is usage can vary in its level of complexity.
3.5 Search Classification Indexes
“Search classification indexes” (or “search directories”) are used to find remote remote services.
If a remote service type becomes associated with a language game then it becomes the concept for that language game. It then makes sense to locate remote services which implement the language game using the remote service type. It thus makes sense to incorporate remote service types into directories and indexes.
For instance, if “part” is associated with the language game for parts then parts might feature in a directory structure which contained
1. commerce.manufact.cameras.parts
2. wws.kate.com*parts
3. commerce.retail.cameras.parts
4. wws.maxim.com*parts
The categories “commerce.manufact.cameras.parts” and “commerce.retail.cameras.parts” lead us to the service entries “wws.kate.com*parts” and “wws.kate.com*parts”. We call this a “remote service index”.
A practice such as “manufacturing parts” is different from a practice such as “selling parts”. But they have the overlapping practice of “parts usage”. For instance, they will both involve a practice such as part identification, which will be the same or similar in each. It is overlapping practice that we locate by using the remote service type.
We could do this for instance in order to determine whether wws.maxim.com sells the same part as wws.kate.com manufactures.
As language games and their associated search types become defined the search types will occur in various combinations with each in search classification indexes as the index entries used to guide the search. They will appear like combinations of common words “part”, “sale”, “definition” , “location” etc. other and are associated search types the search types will occur in search classification indexes. They would “make sense” to an average user.
We would also envisage using existing classification systems such as the Dewey Decimal System or the Library of Congress system.
We can also imagine using supplementary techniques. We could use www key word search to find www sites which feature key words we are interested in. Then see if there are associated wws sites which support the language game we are interested in.
3.6 Search Interpreter Services
If language game implementations were developed then it is reasonable to expect that they would be developed in different directions. For instance, different implementations of the same language game might feature differently names relations. In addition, language games from quite different areas could be developed without reference to each other.
We see Interpreter Services as providing the solution to these problems by providing bridges between different language games.
What an Interpreter Service provides can be explained as follows. If S is an Interpreter Service between two language games L1 and L2 then S provides a language game L3 which provides
· all or some of the relations from both L1 and L2
· rules which show the relations between relations in L1 and L2.
From time to time two language games will adopt the same signs for different relations. Following the xml “name space” practice, in such instances we prefix the relation with the lesser currency (lesser popularity) with the name of the language game implementation.
So say both L1 and L2 have separate definitions of “UnitPrice()”. Say these definitions are incompatible since they have different relations. for instance, they give you a different calculation of TotalPrice(). Then if L2 has lesser currency then L1, L2’s UnitPrice() is now written L2:UnitPrice(). This symbol would only need to be used in contexts which used both L1 and L2’s relation of UnitPrice(). In the case of S translating between processes P1 and P2 where P1 uses L1 and P2 uses L2, S could still communicate with P2 using L2’s relation of UnitPrice().
This is similar to the practice of using scare quotes in languages such as English to indicate an unusual interpretation of a common symbol. If LoonChing likes elegance “”Loonching’s casual” is not my idea of casual”.
Consider the case where the language games L1 and L2 are different implementations of the same purchasing language game. They might use different signs for the supplier. L1 might use “Supplier” whereas L2 uses “Seller”. Then in this case we need a simple rule
(all x) (Supplier(x) -> Seller(x) & Seller(x) -> Supplier(x)
S can use this rule to make the two languages interoperable with respect to supplier.
Consider the different case where the two languages have been developed for very different purposes. For instance, L1 is a purhase order language game and L2 is a legal language game. Then L2 might contain a relation “Company()” which is not in L1. We can partially bridge the gap with a rule
(all x)(Company(x) -> Buyer(x) or Supplier(x))
This may be enough under some circumstances to allow L1 and L2 to be interoperable with respect to company.
3.7 Search Services and Search Agents
We envisage wws would primarily use two different types of services.
“Search Services” are the end-points of communication. They supply the information we seek from their own resources.
“Search Agents” perform searches. They find and contact Search Services, and they may contact other Search Agents, in order to acquire the information we seek.
4) wws Search Processes
4.1 Resolving Remote References
A basic wws process is to fill in know variables in relations and then rely on external services to fill in the unknowns. Section 4.1 illustrates this.
4.2 Leveraging Common Relations
The assumptions of wws is that processes will implement the same language games. This means 1) they will implement the same relations 2) recognize the same rules (relationships between relations).
They may implement all or some of the relations, and they may or may not require interpreter services.
However, if they do implement the same relations then they will be interoperable with repect to those relations.
For instance, if processes P1 and P2 implement the same sales language L, then if they share the same values for the shared relations Quantity(), UnitPrice(), Tax() etc. then they will have the same value for TotalPrice().
We see sharing relations in this way as a solution to the problems of combining services in distributed computing.
4.3 Combining Services
wws relations are implemented as separate relations and they can be combined with any other relations.
If we want to define a processes context we simply list all the relations it has and their values. If we want to define the “context” shared between two different processes we simply list all the relations they share along with their values. Context can be extended at any time by adding new relations. Context is not imposed or restricted by any other structures.
On this model a processes context is just the same as a sentence in predicate calculus which shows all the relations the process affirms to be true. We can imagine a typically long sentence which we call a “model” as follows:
(some t)(some u)(some v)(some w)(some x)(some y)(some z)( P(t) & Q(u) & R(v) & S(w) …
If we wanted to know the shared context of two different processes we would simply find the intersection of their models.
On this model you are free to add a new relation T(x) at any time. You can also combine relations to achieve a result without restriction. See section 4.1.1 for an illustration.
4.4 Finding Services
Finding services would be important in itself.
We envisage that service type identifiers could be used in the construction of search classification indexes. The advantage would be that services found with a service type identifier would be able to perform the service associated with that identifier. Section 4.3 illustrates this.
4.5 Flexibly Using Symbols in Many Contexts
A sign such as “part” in the context of an xml form is generally limited to that context. It has to “carry that context” with it no matter where it goes, even if that context is irrelevant to many of the contexts in which the symbol could be used.
We would be better off using smaller units of meaning such as individual symbols which can be combined together, as well as being used across many different contexts.
Wws tries to achieve this by using relations as its unit of meaning, rather than using forms as its unit of meaning. A relation may be defined in particular language game but we are free to use the relation without restriction on other language games.
See section 6.5 for an illustration.
5) wws Search Process Advantages
The primary benefits we see from wws are:
· High levels of interoperability between processes
· Successful distributed computing
· High levels of process composition.
· Problem solving capabilities.
We describe these below.
5.1 Interoperability
The primary advantage of wws is that it uses remote service references such as Part(x, “M1R10”, “wws.kimikotech.com*parts”) which belong to standard language games such at the “Parts” language game. These references then not only name items, but because they leverage language games they also provide the basic relations associated with the item
In the best possible case all processes involved in a transaction adopt the same remote service definition of the part M1R10, namely, Part(x, “M1R10”, “wws.kimikotech.com*parts”). In this case there need be only one definition of the M1R10 on the web. (We could of course have mirror references.) In this case we can be assured that processes involved in the transaction are “referring to the same thing”. In this case we say that all processes are interoperable with respect to M1R10 as far as it is determined by the language game Parts. In this case we might say that they are adopting the same symbol for an M1R10. We might even go as far as saying that they have the same concept of the M1R10.
If wws had a marketing slogan then it might be “Use a remote service reference and you will be understood.”
5.2 Distributed Computing
We believe that wws provides an effective model for distributed computing.
If processes P1 and P2 implment the same language game Parts then they contain the same relations R1… Rn for Parts. In this case they can assign values to relations and exchange this information. They will be referring “to the same thing”.
But in addition they may implement additional language games. By utilizing their Parts commonality they can then leverage the services of the other without implementing the services of the other.
For instance, P1 may implement the Parts language game and the Sales language game, P2 may implement the Parts language game and the Inventory language game. P1 may utilize its Parts commonality with P2 use to ask P2 what items it has available to sell.
5.3 Process Composition
wws promotes freely mixing relations together.
wws adopts relations as its unit of meaning, rather than forms. Its model is predicate calculus where you can mix terms freely. You might have
(some x) Part(x, “T1R10”, wws.kimikotech.com)
and then add
Color(x, “red”, “wws.colorcom.com”)
You are now operating the Parts language game and the Color language game, but there is no reason why you should not apply them to “the same thing”.
Wws definitions should be more like the definition of words in a dictionary, than of elements in DTDs or schemas. A dictionary is a container for words but it does not constrain them. You are welcome to combine them in sentences in new and different ways.
5.4 Problem Solving
One aspect not discussed here is that many problems, especially practical problems, can be modeled simply as the problem of satisfying all the terms of a large conjunction in predicate calculus. For instance, where to find the car that meets your price, color, performance, environmental, safety, age, style, etc requirements.
As wws uses relations as its model and is in touch with the resources of the web it should provide a powerful problem solving tool.
4) wws Illustrations
4.1 Part Lookup
Imagine that we had a “part” service provided by the remote service “wws.kimikotech.com*part”. This service might be used by companies in buying and selling transactions, shipping, legal, industrial construction and other transactions.
Imagine also that we had a “company” service provided by a remote service “wws.milaninfo.com*company”. This service might provide company attributes such as national business number, last annual report, mission statement, country of residence, stock exchange code, preferred currency etc. It might also provide the remote services that the company supports.
4.1.1 Part Lookup Case 1
In the first case we have a “question” we can express in predicate calculus sentence as
(Some x)(Unknown y)( Part(x, “M1R10”, “wws.kimikotech.com*part”) & PartType(x, y, ““wws.kimikotech.com*part”))
We call this a “question” because it has an “unknown” y which needs to be solved.
We could image expressions like this occurring in a programming language with the programming environment supporting calls to the remote services to have the unknowns resolved.
The way we build up a significant sentence which means something is to primarily feature a variable like x as the “subject” in multiple relations. x is “the thing” we are interested in, and we “determine” what x is by making it the subject of multiple relations. x can also be indirectly effected by other relations in which it is not the subject. In this case the relations determine other variables and these variables feature as the “values” in relations in which x is the subject.
We can also express the same question in xml as follows:
1. <sentence>
2. <some>x</some>
3. <unknown>y</unknown>
4. <Part>
5. <subject>x</subject>
6. <value>M1R10</value>
7. <service>wws.kimikotech.com*part</service>
8. </Part>
9. <PartType>
10. <subject>x</subject>
11. <value>u</value>
12. <service>wws.kimikotech.com*part</service>
13. </PartType>
14. </sentence>
In order to solve a question we need to get the remote services to resolve the unknowns. A parser could automatically make the necessary calls to the remote services.
In order to solve a question a processor can try different strategies. Since the relations specified are independent symbols they can be used indirectly or together. For instance we could send to KimikoTech the sentence
1. <sentence>
2. <some>x</some>
3. <unknown>y<unknown>
4. <PartType>
5. <subject>x</subject>
6. <value>u</value>
7. <service>wws.kimikotech.com*part</service>
8. </PartType>
9. </sentence>
KimikoTech might reply by listing the part types as follows
1. <sentence>
2. <some>x<some>
3. <operator “disjunction”>
4. <operand>
5. <subject>x</subject>
6. <value>compressor</value>
7. <service>wws.kimikotech.com*part</service>
8. </PartType>
9. </operand>
10. <operand>
11. <PartType>
12. <subject>x</subject>
13. <value>drill</value>
14. <service>wws.kimikotech.com*part</service>
15. </PartType>
16. </operand>
17. <operand>
18. <PartType>
19. <subject>x</subject>
20. <value>generator</value>
21. <service>wws.kimikotech.com*part</service>
22. </PartType>
23. </operand>
24. <operand>
25. <PartType>
26. <subject>x</subject>
27. <value>excavator</value>
28. <service>wws.kimikotech.com*part</service>
29. </PartType>
30. <operand>
31. </operator>
32.
33. </sentence>
The unknown u has been resolved by providing the solutions “compressor”, “drill”, “generator”, “excavator”.
In the case of our original question we are trying to determine a unknown value u for x using the service wws.kimikotech.com*part, but we already have a known value for x, the “Part” value “M1R10”, which is determined by the same service. As the known value pertains to the same subject and the same service it is highly likely that it will assist in the determination of the unknown. So it is obvious that both relations should be sent to wws.kimiktech.com*part with it being made clear that they pertain to the same subject x. In this case the easiest thing to do is to send the whole document. If an “M1R10” is a compressor then we would expect the reply
1. <sentence>
2. <some>x<some>
3. <Part>
4. <subject>x</subject>
5. <value>M1R10</value>
6. <service>wws.kimikotech.com*part</service>
7. </Part>
8. <PartType>
9. <subject>x</subject>
10. <value>compressor</value>
11. <service>wws.kimikotech.com*part</service>
12. </PartType>
13. </sentence>
4.1.2 Part Lookup Case 2
In this example we combine the services of two different remote reference services to resolve an unknown. We use wws.untrade.com*commerce.company to find out wws.kimikotech.com’s service identifier for its parts service and we then use this parts service to find out what type of equipment an M1R10 is.
1. <sentence>
2. <some>x</some>
3. <unknown>y</unknown>
4. <some>z</some>
5. <unknown>u</unknown>
6. <Company>
7. <subject>x</subject>
8. <value>KimikoTech</value>
9. <service>wws.untrade.com*commerce.company</service>
10. </Company>
11. <wwsRef>
12. <subject>x</subject>
13. <value>y</value>
14. <value>part</value>
15. <service> wws.untrade.com*commerce.company </service>
16. <wwsSRef>
17. <Part>
18. <subject>z</subject>
19. <value>M1R10</value>
20. <service>y</service>
21. </Part>
22. <PartType>
23. <subject>z</subject>
24. <value>u</value>
25. <service>y</service>
26. </PartType>
27. </sentence>
The first two relations are sent to wws.trade.com. Note “part” has been provided as an additional parameter to define the remote service type required.
wws.untrade.com determines that the following is true
(some x)(some y)(Company(x,”KimikoTech”) & wwsRef(x,”wws.kimikotech.com*part”, “part”).
That is, “there is an x which is a Company KimikoTech, and x has a wwsRef (wws reference service) wws.kimikotech.com*part for the serviced type “part””.
So the solution to y is ,”wws.kimikotech.com*part”. “wws.kimikotech.com*part” can then be supplied as the remote reference service to be used in the last two relations. These last two relations can use this service to determine that the PartType() of an M1R10 is a “compressor”
4.2 Word Translation
To be added.
4.3 Part Location
We may illustrate using service types in Search Classification Indexes as follows.
Imagine person John wants to locate where he can buy a part “L21R21” in his area in Manchester. We might assign the service types “part”, “sale”, “location” in the construction of a search classification index as follows:
1. geography.location
2. wws.worldmap.com
3. …
4. commerce.retail.sale.location
5. wws.newyorkretail.com
6. wws.tokyoretail.com
7. wws.manchesterretail.com
8. …
9. commerce.retail.sale.part
10. wws.bronxreatail.com
11. wws.shinjukuretail.com
12. wws.ardwickretail.com
13. wws.blackleyretail.com
14. …
John has a process which first uses the “location” service type identifier to find the service wws.worldmap.com and ask the question.
(unknown x) Location(x, “Manchester City”, wws.worldmap.com)
The answer is “MN003”. The process then uses the “sale” and “location” service identifiers to locate services which can identify retail outlets for areas. The process asks each of these services if it lists retail outlets for “MN003”. wws.manchesterretail.com does and it gives a large list of the retail outlets in its location. John’s process then uses the “sale” and “part” keywords to find sales outlets. It asks each of the sales outlets in this section of the directory which are also in the list provided by wws.manchesterretail.com if it sells the part L21R21. It finds some that do and the search is successful.
4.4 Car Registration
To be added.
4.5 Security Check
The following is an illustration of how by using the relation as the unit of meaning, rather than the larger unit of form, wws achieves a higher level of flexibility and interoperability.
· Allow wws.patriziatech.com is a sales organization that sells M1R10’s.
· wws.austech.com is an organization that wants to buy M1R10’s.
· wws.searchcentral.com is a Search Agents that can orchestrate sales. Its basic job is to forward information between the buyer and seller.
· wws.sentry1.com is a security organization.
wws.patriziatech.com, wws.austrech.com, wws.searchcentral.com can all work together to perform a sales because they implement the same sales language game. They share the same relations such as Buyer(), Seller(), Part(), Qty(), Price(), Tax() etc. They can therefore interoperate and share information. They may need the services of an Interpreter Service in doing this.
wws.sentry1.com implements a security language game. It ensures that parties in transactions are legally recognized entities. It also ensures that the parts involved in transactions are not subject to export restrictions.
wws.sentry1.com does have the relation Part(). It uses the relation Part() from the standard language game for Part. However, it does not have any of the other relations such as Buyer(), Seller(), Part(), Quantity(), UnitPrice() etc. It does not have to. All it needs to be able to do is recognize that a part is subject to export restrictions, and it will stop the transaction.
wws.sentry1.com has a list of parts subject to export restriction: Part(“C1A1”, “wws.quietsubs.com”), Part(“CV01”,”wws.quietsubs.com”) and Part(“7530”, “wws.shadowplanes.com”).
wws.sentry1.com intercepts wws.search.com intercepts wws.searchcentral.com orchestrating the transaction between wws.austech.com and wws.patriziatech.com. Its asks what Part() is involved. wws.searchcentral.com responds that the part is Part(“M1R10”, “wws.kimikotech.com”). wws.sentryl.com checks its list and the Part(“M1R10”, “wws.kimikotech.com”) is not included. So wws.sentry1.com sends wws.searchsentry.com the “ok continue” signal, and the transaction continues.
4.7 Purchasing Example
See Appendix 1 for a highly detailed simulation of a wws purchasing process.
6) Implementation
Implementation strategy would be a key componet of the success of wws.
There are at least three factors we should consider:
· Ease of use.
· Selection of initial applications.
· Extending the model to free form text.
6.1 Ease of Use
Ease of use was a key component of the enormous success of www. See Berners-Lee in Fensel[2003]. wws should try to emulate this.
We image that like www applications wws applications could be implemented with simple files like html pages or with more complex processes such as cgi scripts, application servers etc.
We imagine that users would be able to write simple files containing sentences of relations an a plug-in in a http server could then use these files to perform the language game. The plug-in would also need to be usable in a browser so that users could perform testing.
6.2 Selection Of Initial Applications
To get the process going it would be useful to try simple applications first. One suggestion would be to begin by having technology suppliers implement a language game to explain bugs which could then be leveraged in their products. Then for example an application to allow consumers to locate retail outlets for products in their location might prove popular.
6.3 Free form text
7) Symbolic Computing
We believe that wws may point to a slightly different model of computing we call “symbolic computing” where the focus is on manipulating sentences composed of relations. Symbolic computing would involve steps such as:
· Adding relations to a sentence.
· Removing relations from a sentence.
· Applying negation to a relation in a sentence.
· Adding sentences together in a group.
· Exchanging a sentence, parts of a sentence, or a group of sentences with a partner that implements the same language game.
· Saving, restoring, deleting, and updating a sentence or a group of sentences.
· Applying a set of rules to a sentence or group of sentences to generate new relations and fire events.
Existing processes could be modified with this process.
We believe that one benefit of this model is that it would be a more lightweight process than generating code. Refining programs to handle different cases involves a lot of labor. Adding rules to a rule store would seem to be a much more lightweight process.
8) SOA Design Tool
If language games were formalized then they could provide a design direction for SOA. SOA analysis could target mapping existing applications to the formalized language games. This would give SOA a clear conceptual direction plus a tool for application interoperability.
9) The Error Of Ontology
We have avoided any discussion of ontology in this paper. Although it is not a critical tenet of what we propose, we would like to say that it is out belief that ontology and other semantic modes which postulate “special object”s are all based on a “simple mistake”. It may be a “simple mistake” but it is a mistake which has had a very good run for a couple of thousand years in philosophy.
We call this mistake the “Operator’s Error”. Imagine an operator operating a mainframe. They have concepts like “file”, “backup”, “shutdown procedure”, “boot procedure”, “signals”, “directory operations” etc. Do these concepts describe the world? Yes, of course they do; they are what allows the operator to perform their duties.
However, what if the operator wanted to understand how the machine “really worked”. It would be a mistake to try to do this by just studying the concepts in the opeator’s manual more deeply. It would be a mistake to invest concepts like “incremental backup” with a special significance such that concepts like incremental backup really revealed special objects that held play in our world. We might be temped to make statements like “”Incremental backups” are different objects from “full backups””. Hence a full backup cannot be an incremental backup.” We might be tempted to think like this until we came across someone for whom all backups were “incremental backups” with the first backup in the sequence having a special status indicated by “full backup”. Then we might come across someone who did not have the concepts of “full backup” or “incremental backup”, but simply did a “backup”, and when they did the restore simply loaded the tapes in sequence as required. We might be tempted to say that there must be a “full backup” and “incremental backup” in the sequence of tapes somewhere, but, think about it, we might be wrong.
The operator’s error is to think that we can get out of the operator instructions more than was put into them. That somehow they can be a source of discovery. The solution to the operator’s problem of how to understand how the machine “really works” is to shift framework; to shift out of the operator’s framework to say a computer science framework.
As language users we are the expert users of language and our meta-language is our “operator’s manual”. We use it to coordinate with each other, explain ourselves, and generally get agreement on how to proceed. Do our concepts describe the world? Yes, of course they do; they are what allow us to operate in the world.
However, what if want to understand how our language “really worked”, to establish how “meaning worked” . It would be a mistake to try to do this by just studying the concepts in the operator’s manual more deeply. We might be tempted to do things like setup special rules such as “Concepts can have only concept attributes, and not, for instance, material attributes, or human attributes.” But then someone comes along and starts talking about “competitive concepts” and we realize that we do understand what they are saying.
Our error is to think that we can get out of our operator instructions more than was put into them. That somehow they can be a source of discovery. That somehow we can mine meaning. The solution to the our problem of how to understand how language “really works” is to shift framework. The framework we have championed here is a “language game” framework, where describe meaning by putting in the context of a practice. We believe this will work. However, the more general suggestion is to find a framework that works.
We believe that the above are just some of the tenets of the philosophy of Ludwig Wittgenstein. See for instance Wittgenstein[1953].
10) Conclusion
The www semantic web proposal proposes to use semantic classification to locate resources over the web. The www web services proposal proposes to provide standards to enable organizations to exchange data and services over the web. Our proposal is to draw upon both.
The proposal is essentially to:
· Establish service provider end-points which participate in well defined language games to leverage symbols and provide services, and which most probably employ formal languages to facilitate sharing common symbols.
· Connect up these end-points using the equivalent of a DNS which organizes language game services into a classification or semantic hierarchy.
The end result hopefully is services which can find each other and can leverage each others services to a very high degree since they share the same symbols.
Key to the project is the deliberate promotion of the widespread use of standard symbols. This requires:
· “Ungluing” signs from their immediate narrow context in individual schemas or DTDs.
· Making the use of standard symbols as widespread as possible by promoting them across groups of people and contexts.
· Defining the pragmatics of symbols clearly so when they applied in new and different contexts they are most probably used in expected and consistent ways.
· Creating language games providing services which emulate human symbol usage, especially with respect to characteristics such as 1) allowing incomplete communication where the communication is built up, 2) allowing the unfettered combination of symbols from many language games.
We suggest that employing a constructive approach where we use a formal language to express relations will facilitate this program. We will then be able to search not just for text or graphics, but for well-know symbols expressed as relations in a formal language.
The key technical device is the “remote service reference”.
The next steps would seem to be:
· Extend and clarify the concepts outlined here.
· Create prototypes
· Establish wws search infrastructure
· Create language games examples expressed in a formal notation.
· Build applications which implement these language games.
Appendices
Appendix 1 provides a highly detailed simulation of how wws might be used to perform purchases.
References
Fensel[2003]. Spinning the Semantic Web. Editied by Dieter Fensel, James Hendler, Henry Lieberman, and Wolfgang Wahlster. Forward by Tim Berners-Lee. MIT Press. 2003 edition.
Wittgenstein[1953]. Philosophic Investigations. Ludwig Wittgenstein. Basil Blackwell and Mott. 1974 edition. (Please note that this is an unusual text, and probably requires some specialization.)
Author : Gerard McGovern
Date : 26/Feb/2006
Version : Preliminary Draft 1.1
email : page7@optusnet.com.au