- From: Drew McDermott <drew.mcdermott@yale.edu>
- Date: Mon, 23 Jun 2003 17:20:42 -0400 (EDT)
- To: www-ws@w3.org
Date: Sat, 21 Jun 2003 20:45:07 +0200 (CEST) X-PH: V4.4@mr1 From: Stanislaw Ambroszkiewicz <sambrosz@ipipan.waw.pl> Although you and me have in mind the same domain (i.e., web services), it seems that we are talking about two different languages and different semantics. ... I agree that it is hopeless to construct the explicit meaning of natural language however some approximations may be interesting and important. The language must be open, i.e., it has to evolve. Moreover, in my opinion, it should be of distributive use, i.e., anyone can introduce new concepts to the language. However, there is a problem with implementing such distributive use, if there are "the committees in charge of ontology" that decide how and what is added to "the ontology". Even if we agree on "the committees" there is another problem how to scale this solution. If the ontology is closed and its consistency is verified, then it seems it is OK even if the ontology is large. What if an ontology is evolving and expanding so that it contains thousands, ... or millions of axioms? My assumption is that there will be multiple ontologies managed in a variety of ways. Business people will probably favor ontologies backed by trade groups. Now, let me explain my point of view. Your solution conveys the concepts from natural language (used in human world) immediately into a language of the emerging world of web services (ws-world for short). I propose to separate the ws-world from the human world, and construct a language only for ws-world along with precise semantics. It is clear that this language must relate to the human world but this will be discussed later on. The ws-world (called also cyberspace) consists of networked (TCP/IP) applications that exchange electronic data and process them; that's all what can happen there. Okay. Humans can influence the ws-world only by user interfaces (e.g., browsers, ssh, email, etc. ). Usually web services as well as user interfaces are placed in the border between these two worlds; they have interfaces to the human world as well as to the ws-world. It may look like science fiction, however I am interested merely in communication language for the ws-world. Requests as well as data are sent to the ws-world via user interfaces. A web service processes input data, and then sends output data to another service; this is what happens on the side of ws-world. On the other side the service may influence the real world as the result of processing this input data. The question is where the language is needed, used, and what its semantics is? _What_ language? Where did language enter into the framework you just described? It is clear that the language is needed to express requests and the types of operation the services perform. It's not clear that the same language is used both to express requests and describe what the service does. We could view WSDL+SOAP as a candidate, but it's precisely because we're stuck at that point that we have to open our minds to new possibilities for the service-description language. There is straightforward interrelation between requests and operation types. i.e., a request is to be realized by (a composition of) services. Hence, there must be a semantic equivalence of a request and of the types of operations that may realize this request. However, this semantics is always in the human world, i.e., on the side of users and the side of service providers; they must know what they want to realize, and what their services perform. I don't understand this paragraph. I don't see why there must be a "semantic equivalence" between a request and the operations that realize it. There might be more than one way (more than one set of operations) to satisfy a request. The point about semantics being "always in the human world" I might grant, but is that the same as knowing what services perform? I thought the whole point of web-service discovery and composition is that the humans and their agents, who are looking for services, _don't_ know what services are out there. The key point is to determine what the language must describe, i.e., what is going on in the ws-world. It seems that nothing but data of some types are processed by operations implemented by services into some other data. How to describe this in the language? The description should abstract from specific data and specific operations. In order to do so, names for data types and names for operation types are needed. Okay. The operation type is intended to have the generic meaning, i.e., to be represented by pair of formulas: precondition and effect (postcondition). These conditions should describe operation interface as well as what this operation does perform; a generic way to do so is by using names that denote abstract functions as in mathematics. I don't see how that will do the trick, if I understand the phrase "functions as in mathematics" properly. A service might give me a confirmation number if I give it a credit-card number. The confirmation number is not a function of the input, but that's not important; the important point is that the most precise description in the world of the format of that confirmation number and how it was generated will not tell me that I now have a right to expect a hotel room to be available at hotel H on date D, and that this number can be given to the clerk to aid in verifying my right. We can introduce names for new types and names for new functions to our language, so it would be nice to introducing also names for new primitive relations. ... Since the axioms were not even mentioned, the question is about the meaning of the language. How do the names get the meaning in this language? The answer is extremely simple. A name gets its meaning by pointing into the place where it was originally defined either as primitive concept or as a complex concept. This very name contains the pointer to this original place. If it denotes a complex concept, then its meaning is defined in the definiendum. If it denotes a primitive concept, then the definition consists only of definiens. Since the name of this primitive concept is unique and points to the very place where it was originally defined (only by definiens), the meaning of this concept is fixed. Anyone who uses this name refers to this very place where it was originally defined. Informal meaning of this concept may be described in a natural language also in this place. You may say that it is a trick, nothing new, and no (machine readable) semantics at all. However, it works. Here we basically agree. I doubt there is a machine-readable semantics, and you propose that symbols are given meanings by being standard URIs. Another way to put it is that URIs behave like proper names. They aren't defined in terms of anything else; they just get attached to their denotations and stick to them. My description is just as empty as yours! Fortunately, the fact that no one yet understands how proper names work does not keep them from working, even when used by computers. In fact, the semantics, or language understanding is always on the side of humans, i.e., users and service providers. I am willing to go along with this idea because it's harmless in most practical contexts. But in the final (philosophical) analysis, computers and people are in the same boat when it comes to semantics. We can both deploy languages, and rely on the fact that the terms of a language tend to stay connected to what they denote. Occasionally the language breaks down, and then both people and machines are revealed to be using meaningless symbols. (Trivial example: our foreign subsidiary gets the new product codes all wrong, so that when we get an order from them for product P, they're actually asking for P', and they will be confused and unhappy about getting what we call a "P".) Fortunately, we can usually repair such problems quickly, especially in a mundane area like web services. -- -- Drew McDermott
Received on Monday, 23 June 2003 17:20:44 UTC