Re: Meaning

   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