W3C home > Mailing lists > Public > www-ws@w3.org > September 2003

Re: Grounding puzzle

From: David Martin <martin@AI.SRI.COM>
Date: Fri, 19 Sep 2003 17:16:01 -0700
Message-ID: <3F6B9C41.7040404@ai.sri.com>
To: Drew McDermott <drew.mcdermott@yale.edu>
Cc: www-ws@w3.org

Drew McDermott wrote:

>    [me]
>    > Suppose there is a web service that works like this:
>    > 
>    >   For all person, residing in the U.S., if you send
>    >               social_sec_no(person) [a string of 9 digits]
>    >   to this service, it will return
>    >               telephone_num(person) [a string of 10 digits]
>    > 
>    > Between WSDL, the DAML-S process, and the grounding, how does this
>    > fact get represented?
>    [Mithun Sheshagiri]
>    The DAML-S atomic process would be the following (I assume here that the 
>    output is unConditional):
>    AtomicProcess: TelLookUp
>    input: sSN
>    unConditionalOutput: phoneNumber
>    sSN is a property that points to a concept called Social_sec_no. This 
>    concept is defined in a profile ontology which also defines the datatype 
>    for this concept (string of 9 digits). The property that associates 
>    Social_sec_no to the upper concept Person is hasSSN
>    Similarly, phoneNumber points to a concept defined in the profile 
>    ontology, Telephone_num. The corresponding property is hasTelNum
>    The grounding would point a WSDL description that uses the 
>    Request-Response transport primitive. Part of the WSDL description would 
>    look like this.
>    message definition:
>    <message name="SSN_Input">
> 	 <part name="sSN" daml-property="profile:#hasSSN"/>
>    </message>
>    <message name="phoneNum_Output">
> 	 <part name="phoneNum" daml-property="profile:#hasTelNum"/>
>    </message>
>    port desription:
>    <portType name="TelLookUp_port">
>    <operation name="TelLookUp_operation" daml-s-process="BT:#TelLookUp">
> 	   <input message="SSN_Input"/>
> 	   <output message="phoneNum_Output"/>
>    </operation>
>    </portType>
>    Now the daml-property in the message description would be used by a 
>    specialized DAML sensitive WSDL processor to pick datatype information 
>    from the profile ontology.
>    I hope this is what you were looking for.
> No.
> I've repeated your entire message in my answer, which I normally try
> to avoid, so that people following this discussion can see that
> nowhere in your solution do you actually say that if I send a Social
> Security number for person P to the service, it will send me the
> telephone number of P, *that very same person* (which is a slight
> idealization, since people can have more than one phone number, or
> less than one).  

Isn't this precisely this sort of thing one could express as either the 
"effect" or the "postcondition" of a service (depending on how that 
terminological distinction gets resolved; I'm pretty sure Michael K. 
would call this a "postcondition").

That is, one would specify SSN as an input, and PhoneNumber as an 
output, and one would have an effect (or postcondition) stating 
something like:

     exists P .
       [person_has_SSN(P, SSN) & person_has_phone(P, PhoneNumber)]

Of course I'm glossing over lots of details about how this gets 
expressed, and how it gets evaluated, BUT - let it just be noted that 
this is a nice, simple illustration of one kind of advantage that the 
Semantic Web will bring to Web services.  (That is, one can certainly 
imagine various matchmakers and planners needing to know this kind of 
information about the service.)

-- David

> Or those same people can see that I've missed
> something obvious, which wouldn't be unheard of.
> Now that I ponder it, the obvious thing I may have overlooked is that
> the statement is mostly captured in the IOPEs of the DAML-S process
> description.  There's really not much left for the WSDL and grounding
> to do except specify port bindings and maybe character sets.  The fact
> that American Social Security numbers and telephone numbers have 9 and
> 10 digits respectively is part of the ontology, as you suggested.
Received on Friday, 19 September 2003 20:15:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:12 UTC