Re: Grounding puzzle

David Martin <martin@ai.sri.com> wrote:
>
> 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)]
> 

Yes, it would be a postcondition in my book. The effect here is null unless
some result of the execution actually becomes part of the new state. But if
the answer is just returned and forgotten then there is no effect, since it
would not be possible to tell at any moment after the execution if the
service did anything or not.


	--michael

Received on Friday, 19 September 2003 22:41:49 UTC